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1 Editor’s Notes 

2 This section will not appear in the final document. It is used for editorial com- 

3 ments concerning this draft. 

4 Draft 1 was mostly the new archive/interchange format, based on Donn Terry’s 

5 work in P1003.1b. See the Introduction for other input the working group needs 

6 to consider. 2 

7 This first draft contained diff marks (l) to differentiate material from Donn’s 2 

8 archive proposal; see 4.48. Diff marks “ 2 ” denote changes from Draft 1 to Draft 2. 3 

9 Diff marks “ 3 ” denote changes from Draft 2 to Draft 1. Editorial changes such as 3 

10 typos, grammatical errors or changes, changes in cross references, and removal of 

11 editorial notes are not diff-marked. Please note that it is not always feasible to 

12 get the diff marks exactly right; they will sometimes start or end a line too soon. 

13 This draft makes assumptions about the organization and content of POSIX.2 

14 Draft 11.2, POSIX.2a Draft 8, and POSIX.la Draft 5. If you are not in one of these 3 

15 balloting groups, you can purchase either draft by contacting: 

16 IEEE Publications 

17 P.O. Box 1331 

is 445 Hoes Lane 

19 Piscataway, NJ 08855-1331 

20 1 (800) 678-IEEE 

21 +1 (908) 562-3800 (outside US) 

22 Since portions of this standard are meant to be modifications of the base POSIX.2 

23 standard, the draft headings in Sections 1 through 6 have been set up to match 

24 the affected clauses and still go into the table of contents. There are therefore 

25 gaps in the clause numbers. 

26 For various editorial reasons, there is a page number gap where the Annexes will 

27 eventually go. 

28 Please report typographical errors to: 

29 Hal Jespersen 

30 POSIX Software Group 

31 447 Lake view Way 

32 Redwood City, CA 94062 

33 +1 (415) 364-3410 

34 FAX: +1 (415) 364-4498 

35 Email:hlj@Posix.C0M 

36 (Electronic mail is preferred.) 
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37 This draft is available in various electronic forms to assist the review process. 

38 Our thanks to Andrew Hume of AT&T Bell Laboratories for providing online 

39 access facilities. Note that this is a limited experiment in providing online access; 

40 future ballots may provide other forms, such as diskettes or a bulletin board 

41 arrangement, but the instructions shown here are the only methods currently 

42 available. Please also observe the additional copyright restrictions that are 

43 described in the online files. 

44 Assuming you have access to the Internet, the scenario is approximately 

45 ftp research.att.com # research's ip address is 192.20.225.2 

46 <login as netlib; password is your email address> 

47 cd posix/pl003.2b/d3 

48 get toe index 

49 binary 

50 get pll-20 . Z 

51 The draft is available in several forms. The table of contents can be found in toe, 

52 pages containing a particular section are stored under the section number, sets of 

53 pages are stored in files with names of the form p n-m, and the entire draft is 

54 stored in all. By default, files are ASCII. A . ps suffix indicates PostScript. A.Z 

55 suffix indicates a compress’ed file. The file index contains a general description 

56 of the files available. 

57 These files are also available via electronic mail by sending a message like 

58 echo send 4.48 from posix/pl003.2b/d3 | 

59 mail netlib@research.att.com 

60 If you use email, you should not ask for the compressed version. For a more com- 

61 plete introduction to this form of netlib , send the message 

62 send help 


63 POSIX.2b Change History 

64 This section is provided to track major changes between drafts. 

65 Draft 3 [February 1992] Miscellaneous minor changes to the pax format, 3 

66 provided by Mark Brown. Symbolic link material added, based on 3 

67 initial proposals from Dawn Burnett, as modified by the working 3 

68 group. 3 

69 Draft 2 [December 1991] Miscellaneous minor changes to the pax format, 2 

70 provided by Mark Brown. Limited online access provided as part 2 

71 of an IEEE Computer Society experiment. 2 

72 Draft 1 [September 1991] Conversion of pax formatting from P1003.1b 

73 Draft 5 and cpio and pax from IEEE Std 1003.1-1990. 
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IEEE Standards documents are developed within the Technical Committees of 
the IEEE Societies and the Standards Coordinating Committees of the IEEE Stan¬ 
dards Board. Members of the committees serve voluntarily and without compen¬ 
sation. They are not necessarily members of the Institute. The standards 
developed within IEEE represent a consensus of the broad expertise on the subject 
within the Institute as well as those activities outside of IEEE that have expressed 
an interest in participating in the development of the standard. 

Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard 
does not imply that there are no other ways to produce, test, measure, purchase, 
market, or provide other goods and services related to the scope of the IEEE Stan¬ 
dard. Furthermore, the viewpoint expressed at the time a standard is approved 
and issued is subject to change brought about through developments in the state 
of the art and comments received from users of the standard. Every IEEE Stan¬ 
dard is subjected to review at least every five years for revision or reaffirmation. 
When a document is more than five years old and has not been reaffirmed, it is 
reasonable to conclude that its contents, although still of some value, do not 
wholly reflect the present state of the art. Users are cautioned to check to deter¬ 
mine that they have the latest edition of any IEEE Standard. 

Comments for revision of IEEE Standards are welcome from any interested party, 
regardless of membership affiliation with IEEE. Suggestions for changes in docu¬ 
ments should be in the form of a proposed change of text, together with appropri¬ 
ate supporting comments. 

Interpretations: Occasionally questions may arise regarding the meaning of por¬ 
tions of standards as they relate to specific applications. When the need for 
interpretations is brought to the attention of the IEEE, the Institute will initiate 
action to prepare appropriate responses. Since IEEE Standards represent a con¬ 
sensus of all concerned interests, it is important to ensure that any interpretation 
has also received the concurrence of a balance of interests. For this reason, the 
IEEE and the members of its technical committees are not able to provide an 
instant response to interpretation requests except in those cases where the matter 
has previously received formal consideration. 

Comments on standards and requests for interpretations should be addressed to: 

Secretary, IEEE Standards Board 
445 Hoes Lane 
P.O. Box 1331 
Piscataway, NJ 08855-1331 

IEEE Standards documents are adopted by the Institute of Electrical and Elec¬ 
tronics Engineers without regard to whether their adoption may involve 
patents on articles, materials, or processes. Such adoption does not assume 
any liability to any patent owner, nor does it assume any obligation whatever to 
parties adopting the standards documents. 
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(This Introduction is not a normative part of P1003.2b Information technology — Portable Operating 
System Interface (POSIX) — Part 2: Shell and Utilities — Amendment 2, but is included for infor¬ 
mation only.) 

HLJ: To be provided. 

Briefly, POSIX.2b consists of minor changes to accomplish the following (from PAR): 

(1) Resolve international comments on ISO/IEC DIS 9945-2 and 9945-2 / DAM 
1 (P1003.2 and P1003.2a). 

(2) Resolve issues resulting from requests for interpretation of the original 
IEEE 1003.2 and 1003.2a documents. 

(3) Improve the clarity, accuracy, and precision of the language in the origi¬ 
nal 1003.2 and 1003.2a documents, correcting deficiencies found in imple¬ 
menting systems, test suites, or applications based on the documents. 

(4) Resolve issues identified by IEEE working groups producing functional 
standards (profiles) that desire finer granularity in groupings of optional 
utilities and features. 

(5) Incorporate interfaces associated with new facilities being produced by the 
P1003. la project, such as symbolic links. (Note: Extended or supplemen¬ 
tary shell and utility features based on P1003. la interfaces will be 
included in P1003.2b only if schedules can be arranged so that the 
P1003. la supplement is available for citation as a normative reference at 
the time of approval of P1003.2b.) 

(6) Assume responsibility for definition of file interchange and archiving for¬ 
mats from P1003.1. This would involve movement of the current section 
10 in IEEE Std 1003.1-1990 and the proposed new format from P1003.1a 
to the clause in P1003.2 that describes the “pax” utility. 

Related Standards Activities 


24 Activities to extend this standard to address additional requirements are in pro- 

25 gress, and similar efforts can be anticipated in the future. 

26 The following areas are under active consideration at this time, or are expected to 

27 become active in the near future: 1) 


28 1) A Standards Status Report that lists all current IEEE Computer Society standards projects is 

29 available from the IEEE Computer Society, 1730 Massachusetts Avenue NW, Washington, DC 

30 20036-1903; Telephone: +1 202 371-0101; FAX: +1 202 728-9614. Working drafts of POSIX 

31 standards under development are also available from this office. 


IV 
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32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 


(1) Language-independent service descriptions of POSIX.l {8} 

(2) C, Ada, and Fortran Language bindings to (1) 

(3) Verification testing methods 

(4) Realtime facilities 

(5) Secure/Trusted System considerations 

(6) Network interface facilities 

(7) System Administration 

(8) Graphical User Interfaces 

(9) Profiles describing application- or user-specific combinations of Open Sys¬ 
tems standards for: supercomputing, multiprocessor, and batch exten¬ 
sions; transaction processing; realtime systems; and multiuser systems 
based on historical models 


44 (10) An overall guide to POSIX-based or related Open Systems standards and 

45 profiles 


46 Extensions are approved as “amendments” or “revisions” to this document, follow- 

47 ing the IEEE and ISO/IEC Procedures. 


48 Approved amendments are published separately until the full document is 

49 reprinted and such amendments are incorporated in their proper positions. 


50 If you have interest in participating in the TCOS working groups addressing these 

51 issues, please send your name, address, and phone number to the Secretary, IEEE 

52 Standards Board, Institute of Electrical and Electronics Engineers, Inc., P.O. Box 

53 1331, 445 Hoes Lane, Piscataway, NJ 08855-1331, and ask to have this forwarded 

54 to the chairperson of the appropriate TCOS working group. If you have interest in 

55 participating in this work at the international level, contact your ISO/IEC national 

56 body. 


Copyright © 1992 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


Introduction 


v 



57 
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59 
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92 When the IEEE Standards Board approved this standard on <date to be pro- 

93 vided>, it had the following membership: 


94 (to be pasted in by IEEE) 
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P1003.2b/D3 


Information technology — Portable Operat¬ 
ing System Interface (POSIX) — Part 2: Shell 
and Utilities — Amendment 2 


Section 1: Revisions to General 


1 1.1 Scope 

2 HLJ: To be provided. See the Introduction. Proposed text is solicited. 


3 1.2 Normative References 


4 = 4 - 1.2 Normative References. Add the following entries to the Normative 

5 References clause in the correct sorted sequence, disregarding the sequence 

6 numbers shown here. 


7 {9} ISO 1001: 1986, Information processing—File structure and labelling of 

8 magnetic tapes for information interchange. 


9 

10 
li 


Issue: The following three standards seem to correspond to ANSI X3.14, 
22, 39, and 54. Someone with access to the actual documents should 
check this assumption carefully. 


12 

13 

14 


{10} ISO 1863: 1976, Information processing — 9-track, 12,7 mm (0.5 in) wide 
magnetic tape for information interchange recorded at 32 rpmm (800 
rpi). 


Copyright © 1992 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


1.2 Normative References 


1 



P1003.2b/D3 


INFORMATION TECHNOLOGY—POSIX 


15 

{11} 

16 


17 


18 

{12} 

19 


20 


21 

{13} 

22 



ISO 3788: 1976, Information processing — 9-track, 12,7 mm (0.5 in) wide 
magnetic tape for information interchange recorded at 63 rpmm (1600 
rpi). 

ISO 5652: 1984, Information processing — 9-track, 12,7 mm (0.5 in) wide 
magnetic tape for information interchange—Format and recording, 
using group coding at 246 cpmm (6250 cpi). 

ISO/IEC 10646: ... , 1) Information technology—Universal Coded Charac¬ 
ter Set (UCS). 


23 1.3 Conformance 

24 There are no revisions to this clause (yet?). 

25 HLJ: There has been some discussion within the profile groups about breaking up 

26 the full Section 4 into smaller groups of required utilities. This is the place to do 

27 that. 


28 

1.4 Test Methods 

2 

29 

To Be Provided. 

2 


1) To be approved and published. 
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1 Revisions to General 



P1003.2b/D3 


Section 2: Revisions to Terminology and General Requirements 


1 Editor’s Note: This section is new for Draft 3. It is not further diff-marked. 3 

2 Editor’s Note: The following material on symbolic links is related to P1003. la / D5; 

3 the definition is from that draft verbatim. All of the symbolic link material in this 

4 and later sections is contingent on P1003.1a being approved before P1003.2b; if it 

5 is not, all of this may be put into an informative annex. When P1003.1a is 

6 approved, a number of the P1003.2 definitions copied from POSIX.1 {8} will be 

7 updated automatically. 

8 2.2.2 General Terms 

9 => 2.2.2 General Terms. Modify the contents of subclause 2.2.2, General Terms, 

10 to add the following definitions in the correct sorted order [disregarding the 

11 subclause numbers shown here]. 


12 2.2.2.201 symbolic link: A type of file that contains a pathname. 

13 The pathname is interpolated into a pathname being resolved, during pathname 

14 resolution, to create a new pathname when it is encountered. [P1003.1a/D5] 

is 2.9.2 Pathname Resolution 

16 => 2.9.1.8 Pathname Resolution. Add a new sentence at the end of the sub- 

17 clause: 

18 When resolving the pathname of file being created, the effects of symbolic links 

19 shall be undefined unless the {POSIX2_SYMLINKS} variable is in effect for the 

20 directory in which the link would be created. 

21 Editor’s Note: The following rationale will be added to E.2.9.1.8, but is kept here 

22 for this draft: 
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2 Revisions to Terminology and General Requirements 


3 



P1003.2b/D3 


INFORMATION TECHNOLOGY—POSIX 


23 Pathname Resolution Rationale. (This subclause is not a part ofP1003.2b) 

24 P1003.1a now includes symbolic links in pathname resolution and a number of 

25 concepts are automatically inherited in POSIX.2 by this inclusion. The large 

26 majority of standard utilities resolve pathnames and operate on files without spe- 

27 cial arrangements for symbolic links. Because of the global POSIX. 1 {8} inheri- 

28 tance, this entails very few modifications to utility descriptions. 


29 2.11.3 Operands 


30 => 2.11.4 Operands (POSIX.l: Def) Add a new paragraph at the end of the sub- 

31 clause: 

32 All of the standard utilities shall be consistent in their processing of symbolic 

33 links specified directly on the command line versus those found elsewhere in 

34 the file hierarchy as a consequence of their operation. 

35 Editor’s Note: The following rationale will be added to E.2.11.4, but is kept here 

36 for this draft: 

37 Operands Rationale. (This subclause is not a part of P1003.2b) 

38 In most cases, the standard utilities follow symbolic links to access individual 

39 files, but when they traverse file hierarchies, they stop descending when they 

40 reach a symbolic link. (The developers of the standard use the informal term 

41 “physical walk” to describe this case.) There are stated exceptions to this (“logical 

42 walks”), such as cp and du. However, none of the utilities treat their command- 

43 line arguments any differently than their encountered files. For example, find 

44 does not follow symbolic links by default. In the following example: 

45 find /foo -print 

46 if /foo is a symbolic link, no output will result, because find treats its argu- 

47 ments consistently with files found during its hierarchy traversal. When modified 

48 to: 

49 find /foo -follow -print 

50 the output would include / foo from the command line and all of the files below it, 

51 including those found in traversing symbolic links. Not all historical practice is 

52 as consistent as the POSIX.2 standard utilities in this regard. 


53 2.13.3 Pathname Variable Values 
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2 Revisions to Terminology and General Requirements 



PART 2: SHELL AND UTILITIES — Amd. 2 


P1003.2b/D3 


54 => 2.13.3 Pathname Variable Values. Add a new subclause, 2.13.3, Pathname 

55 Variable Values, as follows: 

56 The values in Table 2-100 may be constants within an implementation or may 

57 vary from one pathname to another. 

58 Table 2-100 - Pathname Variable Values 

59 

60 Name Description 

61 {POSIX2_SYMLINKS} When referring to a directory, the system supports the creation of sym- 

62 bolic links within that directory; for nondirectory files, the meaning of 

63 {POSIX2_SYMLINKS} is undefined. 

64 _ 


65 Symbolic Constants Rationale. (This subclause is not a part of P1003.2b) 

66 The {POSIX2_SYMLINKS} variable indicates that the underlying operating system 

67 supports the creation of symbolic links in specific directories. Many of the 

68 POSIX.2 utilities that deal with symbolic links do not depend on this value. For 

69 example, a utility that follows symbolic links (or does not, as the case may be) will 

70 only be affected by a symbolic link if it encounters one. Presumably, a file system 

71 that does not support symbolic links will not contain any. This variable does 

72 affect such utilities as In -s and pax that attempt to create symbolic links. 

73 {POSIX2_SYMLINKS} was developed even though there is no comparable 

74 configuration value in P1003.1a. Since POSIX.2 does not depend on a fully com- 

75 forming POSIX. 1 {8} system underneath, the developers of the standard wished to 

76 allow systems in which this was an optional feature, perhaps on a file system 

77 basis. 
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2 Revisions to Terminology and General Requirements 


5 




P1003.2b/D3 


Section 3: Revisions to Shell Command Language 


i There are no revisions to Section 3 (yet). 
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3 Revisions to Shell Command Language 


7 




P1003.2b/D3 


Section 4: Revisions to Execution Environment Utilities 


1 4.5 cd — Change working directory 

2 Editor’s Note: The following rationale will be added to E.4.5, but is kept here with 

3 cd for this draft: 

4 cd Rationale. (This subclause is not a part of P1003.2b) 

5 Some historical shells, such as the KornShell, took special actions when the direc- 

6 tory name contained a dot-dot component, selecting the logical parent of the direc- 

7 tory, rather than the actual parent directory (i.e., it moved up one level toward 

8 the / in the pathname, remembering what the user typed, rather than performing 

9 the equivalent of the C-language call 

10 chdir 

11 In such a shell, the following commands would not be equivalent for all direc- 

12 tories: 

13 cd . . && Is Is . . 

14 This behavior is not consistent with the definition of dot-dot and is not allowed by 

is this standard, although it would be allowed as an extension if triggered by an 

16 environment variable or command-line option. 
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4.5 cd — Change working directory 


9 





P1003.2b/D3 


INFORMATION TECHNOLOGY—POSIX 


17 4.6 chgrp — Change file group ownership 


18 => 4.6.3 chgrp Options. Add the following sentence to the end of the paragraph 

19 describing the -R option: 

20 When a symbolic link is encountered in the file hierarchy, chgrp shall modify 

21 the file referenced by the link and shall continue with the other files in the 

22 directory containing the link, not attempting to follow the link to another por- 

23 tion of the file hierarchy. 

24 Editor’s Note: The following rationale will be added to E.4.6, but is kept here with 

25 chgrp for this draft: 

26 chgrp Rationale. (This subclause is not a part ofP1003.2b) 

27 When chgrp is given a symbolic link as a file operand, it changes the file resolved 

28 from the link. This is a consequence of the dependence on the chowni) functional- 

29 ity, per the Description. The POSIX. 1 {8} chowni) function does not modify the 

30 link itself [and provides no Ichown () function that does that]. However, in 

31 traversing directories for the -R option, it does not follow links into other parts of 

32 the hierarchy. This is based on historical practice. Some systems provide a -h 

33 option that does modify the link itself and this is a valid extension, but it has 

34 been omitted from POSIX.2 because POSIX. 1 {8} does not support it. No known 

35 systems cause -R to follow symbolic links; this functionality is possible with 

36 find ... -follow ... | xargs chgrp ... 
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37 4.7 chmod — Change file modes 

38 => 4.7.3 chmod Options. Add the following sentence to the end of the paragraph 

39 describing the -R option: 

40 When a symbolic link is encountered in the file hierarchy, chmod shall modify 

41 the file referenced by the link and shall continue with the other files in the 

42 directory containing the link, not attempting to follow the link to another por- 

43 tion of the file hierarchy. 

44 => 4.7.4 chmod Operands. Add the following sentence to the end of the para- 

45 graph describing the file operand: 

46 If file is a symbolic link, chmod shall change the mode of the file referenced by 

47 the symbolic link, not the symbolic link itself. 

48 Editor’s Note: The following rationale will be added to E.4.7, but is kept here with 

49 chmod for this draft: 

50 chmod Rationale. (This subclause is not a part of P1003.2b) 

51 When chmod is given a symbolic link as a file operand, it changes the file resolved 

52 from the link. Unlike the chgrp and chown descriptions, where this behavior is a 

53 consequence of the dependence on the chown() functionality, this must be expli- 

54 citly stated for chmod. The POSIX.1 {8} chmodf) function, on which many chmod 

55 implementations will be based, does not modify the link itself [and provides no 

56 Ichmod () function that does that]. However, in traversing directories for the -R 

57 option, it does not follow links into other parts of the hierarchy. No known sys- 

58 terns cause -R to follow symbolic links; this functionality is possible with 

59 find ... -follow ... | xargs chmod ... 
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60 4.8 chown — Change file ownership 


61 => 4.8.3 chown Options. Add the following sentence to the end of the paragraph 

62 describing the -R option: 

63 When a symbolic link is encountered in the file hierarchy, chown shall modify 

64 the file referenced by the link and shall continue with the other files in the 

65 directory containing the link, not attempting to follow the link to another por- 

66 tion of the file hierarchy. 

67 Editor’s Note: The following rationale will be added to E.4.8, but is kept here with 

68 chown for this draft: 

69 chown Rationale. (This subclause is not a part of P1003.2b) 

70 When chown is given a symbolic link as a file operand, it changes the file resolved 

71 from the link. This is a consequence of the dependence on the chown () functional- 

72 ity, per the Description. The POSIX. 1 {8} chown() function does not modify the 

73 link itself [and provides no Ichown () function that does that]. However, in 

74 traversing directories for the -R option, it does not follow links into other parts of 

75 the hierarchy. This is based on historical practice. Some systems provide a -h 

76 option that does modify the link itself and this is a valid extension, but it has 

77 been omitted from POSIX.2 because POSIX. 1 {8} does not support it. No known 

78 systems cause -R to follow symbolic links; this functionality is possible with 

79 find ... -follow ... | xargs chown ... 
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so 4.13 cp — Copy files 


81 => 4.13.2 cp Description. Add the following sentence to the end of the first sen- 

82 tence of the seventh paragraph (beginning “In the following description, 

83 source_file refers ... ”): 

84 When source_file is a symbolic link, cp shall take actions based on the file or 

85 directory referenced by the link, not the contents of the link itself. In travers- 

86 ing the file hierachy with -R or -r, it also shall follow symbolic links to other 

87 parts of the hierarchy. 

88 Editor’s Note: Question for working group: Should the language about infinite 

89 loop detection be copied from find and pax? 

90 Editor’s Note: The following rationale will be added to E.4.13, but is kept here 

91 with cp for this draft: 

92 cp Rationale. (This subclause is not a part ofP1003.2b) 

93 When cp encounters a symbolic link to be copied, it copies the contents of the file 

94 resolved from the link. Unlike many of the other utilities, such as chown or the 

95 default case of find, cp -r and -R do traverse directories by following links into 

96 other parts of the hierarchy. This allows the data in a file hierarchy to be dupli- 

97 cated at another place, such as for backup purposes. 
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98 4.24 find — Find files 


99 => 4.24.4 find Operands. Add the following primary in the proper sorted order: 


100 —follow 

101 
102 

103 

104 

105 

106 

107 

108 

109 

110 
111 


The primary always shall evaluate as true; it shall 
cause find to traverse directories by following sym¬ 
bolic links into other parts of the hierarchy. By 
default, f ind shall not follow symbolic links. In fol¬ 
lowing symbolic links, find shall keep track of the 
directories visited so that it can detect infinite loops. 
(For example, a loop would occur if a symbolic link 
refers to a directory that is an ancestor.) When it 
detects a loop, find shall write a diagnostic message 
to standard error and shall either recover its position 
in the hierarchy in an implementation-defined manner 
or terminate. 


112 => 4.24.4 find Operands. In the -type c description, add the character 1 (ell) 

113 to represent a symbolic link. 
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114 4.33 In — Link files 

115 => 4.33.1 In Synopsis. Modify the Synopsis to be: 

116 In [-f ] source Jile target_file 

117 In [-f ] source Jile... target_dir 

118 In -s source Jile target Jile 

119 In -s source Jile ... target_dir 

120 => 4.33.2 In Description. Modify the entire Description subclause as follows: 

121 The ln{) utility creates either hard or symbolic links, depending on the pres- 

122 ence of the -s option: hard links shall be created by default, symbolic links 

123 with-s. 

124 4.33.2.1 Creating Hard Links 

125 <current contents of 4.33.2 ... > 

126 If source Jile is a symbolic link, In shall follow the link and create a hard link at 

127 destination to the file referenced by source Jile. If either target Jile or target _dir is 

128 a symbolic link, the third or fourth synopsis forms (respectively) shall be 

129 assumed, even though -s was not specified; use of-f in these cases is undefined. 

130 4.33.2.2 Creating Symbolic Links 

131 In the third synopsis form, the In utility shall create a symbolic link for the file 

132 specified by the source Jile operand, at the destination path specified by the 

133 target Jile operand. If target Jile is a symbolic link to a nondirectory file, In shall 

134 overwrite the symbolic link. This third synopsis form shall be assumed when 

135 there are two operands and the second is not an existing directory. 

136 In the fourth synopsis form, the In utility shall create a symbolic link for each file 

137 specified by a source Jile operand, at a destination path in the existing directory 

138 named by target_dir. The corresponding destination path for each source Jile shall 

139 be the concatenation of the target directory pathname, a slash character, and the 

140 last pathname component of the source Jile. If targetjdir is a symbolic link to a 

141 directory, In shall follow the link and create a symbolic link to source Jile in the 

142 directory targetjdir. 

143 For both the third and fourth synopsis forms: 

144 — If the directory in which the destination is to reside does not support 

145 {POSIX2_SYMLINKS}, results are undefined. 

146 — The source Jile operand can be any pathname and need not represent an 

147 existing or accessible file. 


Copyright © 1992 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


4.33 In — Link files 


15 



P1003.2b/D3 


INFORMATION TECHNOLOGY—POSIX 


148 — The source Jile and destination need not reside on the same file system. 

149 — If the last operand specifies an existing file of a type not specified by 

iso POSIX. 1 {8}, the behavior is implementation defined. 

151 For each source Jile: 


152 

153 

154 


(1) If the destination path exists, In shall write a diagnostic message to 
standard error, do nothing more with the current source Jile, and go on to 
any remaining source Jiles. 


155 

156 

157 


(2) Actions shall be performed equivalent to the POSIX. 1 {8} symlink () func¬ 
tion using source Jile as the pname argument, and the destination path 
as the slink argument. 


158 If source Jile is itself a symbolic link, In shall not follow the link, but shall create 

159 a symbolic link in destination to source Jile (the symbolic link) itself. 


160 => 4.33.3 In Options. Add the following option in the proper sorted order: 


161 -s Create symbolic links instead of the default hard links. 


162 => 4.33.4 In Operands. Replace all of the Operands subclause with: 


163 The following operands shall be supported by the implementation: 


164 

165 

166 
167 


source Jile A pathname of a file to be linked. When -s is not specified 
this can be a regular or special file; whether a directory can be 
linked is implementation defined. When -s is specified, any 
pathname can be used. 


168 target Jile The pathname of the new directory entry or symbolic link to be 

169 created. 


170 targetjdir A pathname of an existing directory in which the new direc- 

171 tory entries or symbolic links are to be created. 

172 HLJ: Is it correct that -f cannot be used with -s? 
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173 4.39 Is — List directory contents 


174 => 4.39.1 Is Synopsis. Modify the Synopsis to be: 


175 Is [—CFLRacdilqrtul ] [file ... ] 

176 => 4.39.3 Is Options. Replace the description of the -F option with the follow- 

177 ing: 

178 -F Write a slash (/) immediately after each pathname that is a 

179 directory, an asterisk (*) after each that is executable, a verti- 

180 cal bar (|) after each that is a FIFO, and an at-sign (@) after 

181 each that is a symbolic link. 


182 => 4.39.3 Is Options. Add the following option in the proper sorted order: 

183 -L When a symbolic link is encountered, write the name of the 

184 file or directory the link refers to, rather than the name of the 

185 link itself. 

186 => 4.39.6.1 Is Standard Output. Replace the six-line description of -l (begin- 

187 ning with “If the -1 option is specified, ...”) with: 

188 If the -1 option is specified without -L, the following information shall be writ- 

189 ten: 

190 "%s %u %s %s %u %s %s\n", <file mode>, <number of links>, 

191 <owner name>, <group name>, <number of bytes in the file>, 

192 <date and time>, <pathname> 

193 If the file is a symbolic link, this information shall be about the link itself and 

194 the <pathname> field shall be of the form: 

195 "%s -> %s",<nameoflink>,<contentsoflink> 

196 If both -1 and -L are specified, the following information shall be written: 

197 "%s %u %s %s %u %s %s\n", <file mode>, <number of links>, 

198 <owner name>, <group name>, <number of bytes in the file>, 

199 <date and time>, <pathname oflink> 

200 where all fields except <pathname oflink> shall be for the file resolved from 

201 the symbolic link. 

202 In both of the preceding -1 forms, if <owner name> or <group name> cannot be 

203 determined, they shall be replaced with their associated numeric values using 

204 the format "%u". 
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205 =3> 4.39.6.1 Is Standard Output. Add the following to the list of <entry type> 

206 characters: 


207 1 (ell) Symbolic link 


208 4.43 mv — Move files 

209 => 4.43.2 mv Description. Replace the first two paragraphs of the Description 

210 with: 

2 11 In the first synopsis form, the mv utility shall move the file named by the 

212 source_file operand to the destination specified by the target_file. This first 

213 synopsis form is assumed when the final operand does not name an existing 

214 directory and is not a symbolic link referring to an existing directory. 

215 In the second synopsis form, mv shall move each file named by a source_file 

216 operand to a destination file in the existing directory named by the targetjdir 

217 operand, or referenced if targetjdir is a symbolic link. The destination path for 

218 each source Jile shall be the concatenation of the target directory, a single 

219 slash character, and the last pathname component of the source Jile. This 

220 second form is assumed when the final operand names an existing directory. 

221 => 4.43.2 mv Description. Replace the first sentence of item (5) with: 

222 The file hierarchy rooted in source Jile shall be duplicated as a file hierarchy 

223 rooted in the destination path. If source Jile or any of the files below it in the 

224 hierarchy are symbolic links, the links themselves shall be moved, rather than 

225 any files they refer to. 

226 Editor’s Note: The following rationale will he added to E.4.43, but is kept here 

227 with mv for this draft: 

228 mv Rationale. (This subclause is not a part ofP1003.2b) 

229 When mv is dealing with a single file system and source Jile is a symbolic link, the 

230 link itself is moved as a consequence of the dependence on the POSIX. 1 {8} 

231 rename () functionality, per the Description. Across file systems, this has to be 

232 made explicit. 
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233 4.48 pax — Portable archive interchange 


234 => 4.48.3 pax Options. Add the following option in the proper sorted order: 3 


235 

236 

237 

238 

239 

240 

241 

242 


-L Follow all symbolic links by traversing the the pathnames that the 3 
links reference. In following symbolic links, pax shall keep track of 3 
the directories visited so that it can detect infinite loops. (For exam- 3 
pie, a loop would occur if a symbolic link refers to a directory that is 3 
an ancestor.) When it detects a loop, pax shall write a diagnostic 3 
message to standard error and shall either recover its position in the 3 
hierarchy in an implementation-defined manner or terminate. The 3 
default behavior shall be to archive the symbolic link itself. 3 


243 => 4.48.3 pax Options. Modify the description of the -o options option as fol- 

244 lows: 


245 

246 

247 

248 

249 

250 

251 

252 

253 

254 

255 

256 

257 

258 

259 

260 
261 

262 

263 

264 

265 

266 

267 

268 

269 

270 

271 


-o options 

Provide information to the implementation to modify the algorithm 
for extracting or writing files that is specific to the file format 
specified by -x. The value of options shall consist of one or more 
comma-separated keywords of the form: 

keyword[=value][, keyword[=value \, ... ] 

Within the optional value field, the application shall precede any 
literal comma with a backslash, which shall be ignored, but 
preserves the comma as part of value. Multiple -o options can be 
specified. The following keyword values of options shall be supported 
for the file formats as indicated: 

charmap -name 

HLJ: I have included a modification of the POSIX.2 Draft 
11 -e charmap option to get the working group started on 
the pathname translation problem. I am not personally 
recommending this method, but WG15 has indicated that 
something similar would be necessary. 

The name value shall represent either a system-provided 
charmap description (see 2.4.1) or the pathname of an 
application-provided charmap file. 

With the —w option, filenames shall be written using only 
characters in the portable character set (except NUL; see 
Table 2-3). Any character in the filename that is not in the 
portable character set shall be replaced by pax using the 
following steps; the description refers to the escape charac¬ 
ter defined in the named charmap (see the description of 
escape_char in 2.4.1): 
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272 

273 

274 


(1) Any less-than, greater-than, and escape characters 
shall have an escape character inserted into the 
filename immediately before the character. 


275 

276 

277 

278 

279 


(2) Any character in the filename that is not part of the 
portable character set shall be replaced with a string 
consisting of a less-than character, the symbolic name 
of the character from the charmap, and a greater-than 
character. 


280 

281 

282 


(3) Any escape, less-than, or greater-than characters in 
the replacing symbolic names shall be modified as in 
step (1). 


283 

284 

285 

286 


If a character for which no corresponding symbolic name 
exists in the charmap is found in a filename, pax shall 
write a diagnostic message to standard error; whether the 
file is written to the archive is unspecified. 


287 With the -r option, or if neither the -r or -w option is 

288 specified, the following steps shall be used: 


289 

290 

291 

292 

293 


(1) Any sequences of a less-than character, not immedi¬ 
ately preceded by an odd number of escapes, a string, 
and a greater-than character not immediately pre¬ 
ceded by an odd number of escapes, shall be modified 2 
as follows: 2 


294 

295 


(a) The leading less-than character and trailing 
greater-than character shall be removed. 


296 

297 

298 

299 


(b) Any sequences of an escape followed by an 
escape, less-than, or greater-than character 
shall have the leading escape character 
removed. 


300 

301 

302 

303 

304 


(c) The sequence shall be replaced with the encoded 
value of the character represented by the result¬ 
ing symbolic name, from the charmap. If no 
encoding exists, the modifications to the 
sequence are implementation defined. 


305 

306 

307 


(2) Any sequences of an escape followed by an escape, 
less-than, or greater-than character shall have the 
leading escape character removed. 


308 

309 

310 

311 

312 


linkdata 

(Applicable to the -x pax format.) When the -w option is 
given, but the -r is not, write the contents of a file to the 
archive even when that file is merely a hard link to a file 
whose contents have already been written to the archive. 
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313 

314 

315 

316 

317 


nolog 

(Applicable to the -x pax format.) Suppress logging of 
ignored records and fields. See 4.48.7.2. Messages 
specifically described as error messages shall not be 
suppressed by this option. 


318 notrans 2 

319 Suppress translation of character data or filenames, even 2 

320 when the character set or charmap is known. This option 2 

321 shall override the charmap option described previously. 2 


322 

323 

324 

325 

326 


volid =id 

(Applicable to the -x pax format.) Specify a volume 
identifier for the VOL1 label. See 4.48.7.5.1.2. If fewer 
than six octets are given for id, the value shall be padded 
at the end with <space>s. 


327 => 4.48.3 pax Options. Modify the description of the -x format option as fol- 

328 lows: HLJ: The changes to this are pointers to the Extended Description 

329 instead of POSIX.l and the new pax format; these are diff-marked. The rest is 

330 the same as the 199x standard. 


331 -x format Specify the output archive format. The pax utility shall recog- 

332 nize the following formats: 


333 

334 

335 

336 

337 

338 


cpio The extended cpio interchange format specified 

in 4.48.8. The default blocksize for this format for l 
character special archive files shall be 5120. 
Implementations shall support all blocksize 
values less than or equal to 32 256 that are multi¬ 
ples of 512. 


339 

340 

341 

342 

343 

344 

345 


pax The interchange format specified in 4.48.7. The l 
default blocksize for this format for character spe- l 
cial archive files shall be 10240. Implementa- l 
tions shall support all blocksize values less than l 
or equal to 32 256 that are multiples of 512. HLJ: l 
That was copied from cpio. Should it be 20000 l 
instead? What about multiples? l 


346 

347 

348 

349 

350 

351 


ustar The extended tar interchange format specified in l 
4.48.9. The default blocksize for this format for l 
character special archive files shall be 10240. 
Implementations shall support all blocksize 
values less than or equal to 32 256 that are multi¬ 
ples of 512. 


352 Implementation-defined formats shall specify a default block 

353 size as well as any other block sizes supported for character 

354 special archive files. 
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355 Any attempt to append to an archive file in a format different 

356 from the existing archive format shall cause pax to exit 

357 immediately with a nonzero exit status. 


358 => 4.48.6.1 pax Standard Output. Replace the first paragraph with: 

359 If the —w option is specified and neither the -f nor -r options are specified, the 

360 standard output shall be the archive formatted according to one of the 

361 specifications in the following subclauses or some other implementation- l 

362 defined format. (See -x format under 4.48.3.) l 


363 => 4.48.6.3 pax Output Files. Replace the second paragraph with: l 

364 If the —w option is specified, but the -r option is not, the output file named by l 

365 the -f option argument shall be a file formatted according to one of the l 

366 specifications in the following subclauses or some other, implementation- l 

367 defined, format. l 


368 => 4.48.7 pax Extended Description. Replace this subclause with three sub- 

369 clauses, as follows. This will also cause the renumbering of 4.48.8 and 4.48.9 

370 to be 4.48.10 and 4.48.11. HLJ: This was done for the editorial reason that we 

371 cannot go too deeply into the heading levels and if this were all in 4.48.7, we 

372 would have to start at the fourth level for each format, leaving little maneuver- 

373 ing room. 
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374 4.48.7 Extended Description — pax Interchange Format l 

375 This format is based upon ISO 1001 {9}; a magnetic tape conforming to this stan- 

376 dard also conforms to ISO 1001. The headers of these formats are defined (by 

377 ISO 1001) to use a subset of the invariant part of the characters and codings of 

378 ISO/IEC 646 {1}. There is an exception for certain names that would reasonably 

379 be in a different or larger character set. 

380 4.48.7.1 Definitions 

381 The following terms are used in this subclause (4.48.7). 

382 4.48.7.1.1 a-character: 

383 The 57 characters: 

384 <space> !"%&' ()*+,-./:;<=>?_ 0-9 A-Z 

385 as defined by ISO/IEC 646 {1}. 

386 (The ISO 1001 definition is more elaborate, but equivalent.) 

387 4.48.7.1.2 alternate character set: 

388 A character set specified in the label records in which certain data fields may be 

389 encoded. 

390 4.48.7.1.3 al-characters: 

391 The a-characters (ISO 1001 {9}) plus a-z. 

392 4.48.7.1.4 archive: 

393 A file or medium recorded in the format specified in this subclause (4.48.7). 

394 4.48.7.1.5 block: 

395 When the medium is magnetic tape or another device that records information in 

396 discrete units that have a variable length: the meaning defined in ISO 1001 {9}. 

397 A group of octets recorded consecutively in accordance with the relevant 2 

398 standard for recorded magnetic tape. [ISO 1001.] 

399 Otherwise, it is a quantity of data operated on as a single unit. 

400 4.48.7.1.6 file section: 

401 That part of a file that is recorded on any one volume. [ISO 1001.] 

402 4.48.7.1.7 folded to a-characters: 

403 A string of characters when converted to contain only a-characters, as defined in 

404 4.48.7.2. 
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405 

406 

407 

408 

409 

410 

411 

412 

413 

414 

415 

416 

417 

418 

419 

420 

421 

422 

423 

424 

425 

426 

427 

428 

429 

430 

431 

432 

433 

434 

435 


4.48.7.1.8 label: 

A record that identifies and characterizes a volume, or a file section on a volume. 
[ISO 1001.] 

4.48.7.1.9 log: 

Write to pax standard error. l 

2 

4.48.7.1.10 magnetic tape: 

Media as defined by ISO 1863 {10}, ISO 3788 {11}, and ISO 5652 {12}. [ISO 1001.] 

4.48.7.1.11 record (noun): 

Related data treated as a unit of information. [ISO 1001.] 

4.48.7.1.12 record (verb): 

When discussing the content of an archive, to transfer data from the file hierarchy 
to the archive. 

4.48.7.1.13 restore: 

Transfer data from the archive to the file hierarchy. 

4.48.7.1.14 tape mark: 

A control block used as a delimiter. [ISO 1001.] 

NOTE: The structure of tape marks is specified by the relevant standards for recorded magnetic 
tape. 

4.48.7.1.15 volume: 

When referring to magnetic tape, this shall have the same meaning as in 
ISO 1001 {9}: 

A dismountable reel of magnetic tape. [ISO 1001.] 

When referring to other media, it shall refer to dismountable media. It shall refer 
to the content of a regular file when this format is recorded in a regular file. 

The following notation is used in tables describing record formats: 

BP Octet position within the label 2 

L Length of the field in number of octet positions 

digit(s) Any digit from 0 through 9. 

P When this field in a table is marked, it indicates that a more specific 

requirement than that of ISO 1001 {9} is made. 
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436 4.48.7.2 General Requirements 

437 This subclause is an extension to ISO 1001 {9}; conflicts (as opposed to further 

438 specification) with ISO 1001 shall be resolved in favor of ISO 1001. 

439 When restoring from an archive, the process invoking pax might not have the l 

440 appropriate privileges to create files with all the characteristics described in the l 

441 archive. In such a case, the file shall be created with as many of the characteris- 

442 tics that it had in the archive as the privileges of the process and the system 

443 implementation permit. In the case of a process that has no additional privileges, 

444 the protection information (ownership and access permissions) shall be set in the 

445 same fashion that the POSIX.1 {8} open () function would when given the mode 

446 argument matching the file permissions supplied by the mode field supplied in 

447 the File Information File (see 4.48.7.6). A process with permissions to do so shall 

448 be capable of restoring the ownership, permissions, and other file characteristics 

449 exactly as recorded on the medium. 

450 The pax utility has various options that systematically change the names of files l 

451 on the archive or as restored to the file hierarchy. For simplicity, the rest of this 

452 description is written as if such name changes were not made; pax shall operate 

453 in such a fashion that the relationship between files specified by links and sym- 

454 bolic links is retained in the presence of such changes, to the extent permitted by 

455 the organization of the file hierarchy. 

456 It is implementation defined what protections are applied to an archive based 

457 upon protection fields recorded in it. Interpretation of the protection fields need 

458 not be applied until the information has been restored. 

459 When a device that records data in discrete units of variable length is used, a 

460 block may be longer than the record or records it contains. The pax utility shall l 

461 deal with the extra information in such a way that the extra octets do not partici- 

462 pate in the data recorded on the archive. 

463 When a device that does not support discrete units of variable length is used, a 

464 block shall be exactly the specified length. 

465 When logging of information is required by this standard, the name of the file (as 

466 it appears in the FIF) shall be included in the log in such a way that it can be 

467 associated with the other logged information for that file. 

468 Throughout this subclause, it is stated that certain fields, records, and labels 

469 “shall be ignored.” Such items (if present) may be recorded with any value con- 

470 sistent with ISO 1001 {9}. Nothing in this standard shall be construed to require 

471 that these fields shall be ignored in the presence of options to pax enabling l 

472 interpretation of some or all of these fields. However, such fields shall be ignored 

473 when such options are not used. The existence and content of such items may be 

474 logged. Logging of ignored information can be suppressed by the pax -o nolog l 

475 option. l 

476 A string shall be folded to a-characters to fit in a specific field in a label subject to 

477 the following constraints: 
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478 

479 

480 


(1) The character set is converted to ISO/IEC 646 IRV {1}; characters not in 
ISO/IEC 646 {1} IRV shall be converted in an implementation-defined 
manner. 


481 

482 

483 


(2) The characters a-z are converted to A-z. 

(3) The string is truncated to the field width, or padded with <space>s on 
the right, as needed to make it exactly the width of the label field. 


484 4.48.7.3 Media 

485 The originator and recipient of the volume used for interchange shall agree on the 

486 media upon which this format is to be recorded. If that media is agreed to be 

487 magnetic tape, a tape mark shall be recorded and expected on the medium in the 

488 locations defined below. Where an analogous concept exists for other media, it 

489 should be used. 

490 Where a tape mark or other out-of-band end-of-file marker is not defined for the 

491 agreed-to media it shall be omitted from the media when the interchange format 

492 is recorded. 


493 4.48.7.4 File Representation 

494 An instance of this archive format shall consist of one or more volumes. Each 

495 volume shall contain zero or more file sections. A file shall be recorded in one or 

496 more file sections consistent with the rules of ISO 1001 {9}. 

497 Where tape marks are available, multiple File Sections and the appropriate End 

498 of File or Section and End of Volume Label Groups shall be used. An archive 

499 written on magnetic tape shall use tape marks. 

500 On media where both a tape mark or equivalent is not used, and where records 

501 are not delimited in hardware or where this fact is hidden by the underlying sys- 

502 tern, only a single logical volume shall be written, which may span several physi- 

503 cal volumes. Both the labels and the file data shall be combined as a single 

504 stream, and the labels shall appear immediately adjacent to each other. If the 

505 archive must span more than one physical volume, the last octet from the archive 

506 that is recorded on the first physical volume shall be the one preceding the first 

507 octet recorded on the second physical volume. 

508 On media where a tape mark or equivalent is not used, but where records are del- 

509 imited in hardware, only a single logical volume may be written, which may span 

510 several physical volumes. Each label shall appear as a separate physical record. 

511 File data shall be treated as a single stream. If the archive must span more than 

512 one physical volume, the last octet from the archive that is recorded on the first 

513 physical volume shall be the one preceding the first octet recorded on the second 

514 physical volume. 

515 Media recorded in conformance with this standard shall have volume header and 

516 trailer labels as described below. Such media shall represent each POSIX file in 

517 either one or two ISO 1001 {9} format files. The first such ISO 1001 file shall 
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518 consist of labeling information as described for the File Information File (FIF). 

519 The second section, the File Data File (FDF), is optional—when the FIF describes 

520 a file that does contain data, it shall not be recorded. 

521 4.48.7.5 Volume Label Records 

522 This subclause specifies how each volume label field is defined in the context of 

523 this standard. 


524 4.48.7.5.1 The VOL1 Header Label 


525 

BP 

Field Name 

L 

P 

Content 

526 

1-3 

Label Identifier 

3 


VOL 

527 

4 

Label Number 

1 


1 

528 

5-10 

Volume identifier 

6 


a-characters 

529 

11 

Volume accessibility 

1 


a-character 

530 

12-24 

(Reserved for future standardization) 

13 


<space>s 

531 

25-37 

Implementation Identifier 

13 

* 

a-characters 

532 

38-51 

Owner Identifier 

14 

* 

a-characters 

533 

52-79 

(Reserved for future standardization) 

28 


<space>s 

534 

80 

Label Standard Version 

1 


4 


535 4.48.7.5.1.1 Fields Reserved for Future Standardization 

536 These fields shall be reserved for future standardization for ISO 1001 {9} and its 

537 successors. The characters in these fields shall be <space>s. 

538 4.48.7.5.1.2 Volume Identifier 

539 This field shall specify an identification of the volume. When pax creates a l 

540 volume, the -o volid option can be used to set this field. If this field is not set l 

541 explicitly it shall contain spaces. When pax interprets a volume, this field shall l 

542 be logged. 1 

543 4.48.7.5.1.3 Volume Accessibility 

544 HLJ: Help from 1003.6 is requested in this area. 

545 It is unspecified whether any mechanism is present to control access to files as 

546 recorded in this format based upon any identifying information or security infor- 

547 mation recorded with the file. 

548 4.48.7.5.1.4 Implementation Identifier 

549 This is a constant for the archive format, as opposed to implementation defined 

550 for ISO 1001 {9}. It is implementation defined whether pax will attempt to read a l 

551 file or other media in ISO 1001 format that does not contain the values specified 

552 for these fields. 
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553 4.48.7.5.1.5 Owner Identifier 

554 This field shall contain a representation of the user name associated with the uid 

555 of the process creating the archive file, as found in the user database. The name 

556 shall be folded to a-characters. 

557 4.48.7.5.2 The VOL2 Header Label 

558 This header label is optional; if omitted, the fields described in the record shall all 

559 take their default values. 


560 

BP 

Field Name 

L 

P 

Content 


561 

1-3 

Label Identifier 

3 


VOL 


562 

4 

Label Number 

1 


2 


563 

5-9 

POSIX Identification 

5 

* 

POSIX 

3 

564 

10 

POSIX Version 

1 

* 

1 

3 

565 

11-15 

Standards Body 

5 

* 

a-characters 

3 

566 

16-20 

Number 

5 

* 

a-characters 

3 

567 

21-25 

Variant 

5 

* 

a-characters 

3 

568 

26-29 

Revision 

4 

* 

a-characters 

3 

569 

30-80 

Reserved for POSIX use 

51 

* 

<space>s 

3 


570 NOTE: The reservation of BP 30-80 is an extension from ISO 1001 {9}; in that standard, labels VOL2 3 

571 through VOL9 are reserved for implementation use. 2 

572 4.48.7.5.2.1 Character Set Identification 

573 The four fields Standards Body, Number, Variant, and Revision are used to iden- 

574 tify the alternate character set used in data files, file names, and user and group 

575 names. The following are defined to refer to known standards. Additional names 

576 may be agreed on between the originator and the recipient. If a name is not 

577 recognized, pax may take implementation-defined actions, but there shall always l 

578 be a way for the data to be transferred to the receiving system, possibly without 

579 translation. 


580 

Body 

Number 

Variant 

Revision 

Formal Standard 

581 

<space>s 

<space>s 

<space>s 

<space>s 

ISO/IEC 646 IRV {1} 

582 

ISO 

64 6 

IRV 

1990 

Note 1 

583 

ISO 

8859 

1 

1987 

ISO 8859-1 {5} 

584 

ISO 

8859 

2 

1987 

ISO 8859-2 {6} 

585 

ISO/IEC 

10646 

Note 2 

19xx 

ISO/IEC 10646 {13} 


586 NOTES: 

587 (1) In this form of entry, when the value for variant is irv, then ISO/IEC 646 IRV {1} is specified. 

588 Other values specify National Usage variants of this character set, and shall be agreed upon 

589 by sender and recipient. 

590 (2) This value specifies the compaction method used. 

591 HLJ: Working group input needed for the following. See my sample -o charmap l 

592 description. l 
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593 The format-reading utility shall provide a means to control whether data files 

594 have character set translation applied. This may be done either on a per-file 

595 basis, or selecting the option for the whole archive. A utility that performs the 

596 same translation should be provided. 


597 4.48.7.5.3 The VOL3 Header Label 2 

598 This label shall be used in those instances where a volume spans more than one 2 

599 physical medium, and the normal end-of-section labels could not be written (due 2 

600 to device/driver limitations, for example). 2 


601 

BP 

Field Name 

L 

P 

Content 

2 

602 

1-3 

Label Identifier 

3 


VOL 

2 

603 

4 

Label Number 

1 


3 

2 

604 

5-7 

Media Continuation Identifier 

3 


EOM 

2 

605 

8-11 

Media Continuation Number 

4 


digits 

2 

606 

12 

FIF/FDF Identifier 

1 

* 

(h or D) 

2 

607 

13-29 

File Identifier 

17 

* 

4.48.7.6.1.1 

2 

608 

30-33 

File Section Number 

4 


4.48.7.6.1.3 

2 

609 

34-38 

POSIX Identification 

5 

* 

POSIX 

2 

610 

39 

POSIX Version 

1 

* 

1 

2 

611 

40-45 

Implementation Identification 

6 

* 

<space>s 

2 

612 

46-80 

(Reserved for future standardization) 

7 


<space>s 

2 


613 4.48.7.5.3.1 Media Continuation Number 2 


614 This field shall contain the count, starting from zero (0), of the physical media 2 

615 used to write the volume. The first continuation tape shall be numbered 0001 2 

616 (the initial tape being 0000). 2 

617 4.48.7.5.4 The VOL4-9 and UVL1-9 Header Labels 2 

618 These labels are free to be used for any implementation-defined purpose; they 1 

619 shall be ignored on input. It is implementation-defined as to whether they are 1 

620 included in output. 1 

621 4.48.7.6 File Information File 

622 This subclause specifies how the File Information File (FIF) is recorded; both its 

623 content and the header labels for it are defined. A FIF consists of ISO 1001 {9} 

624 header labels that define the content of the FIF; the FIF itself contains the infor- 

625 mation necessary to recreate the POSIX file (except the data). 

626 4.48.7.6.1 First FIF Header Label (HDR1) 

627 This record shall be recorded for all files in the archive. 
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628 

BP 

Field Name 

L 

P 

Content 


629 

1-3 

Label Identifier 

3 


HDR 


630 

4 

Label Number 

1 


1 


631 

5-21 

File Identifier 

17 

* 

a-characters 


632 

22-27 

File Set Identifier 

6 


a-characters 


633 

28-31 

File Section Number 

4 


digits 


634 

32-35 

File Sequence Number 

4 


digits 


635 

36-39 

Generation Number 

4 


digits 


636 

40-41 

Generation Version Number 

2 


digits 


637 

42-47 

Creation Date 

6 

* 

See 4.48.7.6.1.7 

1 

638 

48-53 

Expiration Date 

6 

* 

See 4.48.7.6.1.8 

3 

639 

54 

File Accessibility 

1 


a-characters 


640 

55-60 

Block Count 

6 


000000 

1 

641 

61-73 

Implementation Identification 

13 

* 

<space>s 

3 

642 

74-78 

POSIX Identification 

5 

* 

POSIX 

3 

643 

79 

POSIX Version 

1 

* 

1 

3 

644 

80 

FIF Identifier 

1 

* 

H 

3 


645 4.48.7.6.1.1 File Identifier 

646 This shall be the name of the FIF file. It shall be derived from the name of the 

647 POSIX file being recorded by prefixing the string info- to the filename (not path- 

648 name) of the file being recorded, with the result folded to a-characters. 

649 4.48.7.6.1.2 File Set Identifier 

650 This field shall be ignored. 

651 4.48.7.6.1.3 File Section Number 

652 This field shall be as specified in ISO 1001 {9}. 

653 4.48.7.6.1.4 File Sequence Number 

654 This field shall be ignored. 

655 4.48.7.6.1.5 Generation Number 

656 This field shall be ignored. 

657 4.48.7.6.1.6 Generation Version Number 

658 This field shall be ignored. 

659 4.48.7.6.1.7 Creation Date 


660 This shall be the representation of the POSIX. 1 {8} stjctime field of the file, con- 

661 verted to a Julian day, according to the time zone active at the time pax was run. l 

662 The Julian date shall appear in the six octets as follows: l 

663 1 If the first two digits of the year are 19, this octet shall be a <space>; l 

664 otherwise, it shall be 0. l 
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665 2-3 These two octets shall be the two least significant digits of the year. 1 

666 4-6 These three octets shall be the three-digit ordinal number of the day l 

667 from 001 to 366. l 

668 4.48.7.6.1.8 Expiration Date 

669 This shall be the same value as the creation date; see 4.48.7.6.1.7. 3 

670 4.48.7.6.1.9 File Accessibility 

671 HLJ: Help from 1003.6 is solicited. 

672 The content of this field may be any permissible value; pax shall ignore this field. l 

673 4.48.7.6.1.10 Block Count 

674 This field shall be as specified in ISO 1001 {9}. 


675 4.48.7.6.2 Second File Header Label (HDR2) 


676 

BP 

Field Name 

L 

P 

Content 

677 

1-3 

Label Identifier 

3 


HDR 

678 

4 

Label Number 

1 


2 

679 

5 

Record Format 

1 

* 

D 

680 

6-10 

Block Length 

5 

* 

20000 

681 

11-15 

Record Length 

5 

* 

09999 

682 

16-20 

Standards Body 

5 

* 

a-characters 

683 

21-25 

Number 

5 

* 

a-characters 

684 

26-30 

Variant 

5 

* 

a-characters 

685 

31-34 

Revision 

4 

* 

a-characters 

686 

35-50 

(Reserved for Implementation) 

16 


not specified 

687 

51-52 

Offset Length 

2 

* 

00 

688 

53-80 

(Reserved for Standard) 

28 


<space>s 


689 4.48.7.6.2.1 Standards Body, Number, Variant, Revision 

690 These fields record the same information, and are encoded in the same way, as 

691 the corresponding fields in the VOL2 Header Label. They specify the alternate 

692 character set to be used in the FIF file for those fields permitted to be in the alter- 

693 nate character set. If all these fields are spaces, instead of indicating ISO/IEC 646 

694 {1} IRV, the alternate character set specified in the VOL2 label shall be used. 

695 4.48.7.6.2.2 Record Format 

696 Data is recorded as variable length records, blocked between 20 and 20K octets 

697 per block. 
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698 4.48.7.6.2.3 Block Length 

699 This is the maximum length of a block, which is 20 000 octets. 

700 4.48.7.6.2.4 Record Length 

701 This is the maximum length of a record, which is limited to 9999 octets by the 

702 structure of variable-length records. 

703 4.48.7.6.2.5 Offset Length 

704 This field shall be zeroes. 2 

705 4.48.7.6.3 Additional File Header Labels (HDR3-9, UHL?) 2 

706 For a FIF, these labels are free to be used for any implementation purpose, and 

707 shall be ignored on input. It is implementation-defined as to whether they are l 

708 written on output. On media that supports tape marks, the last header shall be 

709 followed by a tape mark. On other media the tape mark shall be omitted. 

710 4.48.7.6.4 FIF Contents 

711 The FIF shall consist of several fixed record types of variable length, in the order l 

712 specified below. Each logical record shall be recorded in ISO/IEC 646 {1} IRV, 

713 except that certain fields may be recorded in the alternate character set. Addi- 

714 tional optional record types are permitted in the format specified below. In the 

715 record descriptions below, the content is described excluding the record length as 

716 specified in ISO 1001 {9}. 

717 Records present in a FIF, but which are not recognized by pax, shall be ignored. l 

718 4.48.7.6.4.1 FIF Filename Record 


719 

BP 

Field Name 

I. 

Content 


720 

1 

File Type 

1 

al-characters 


721 

2-10 

File Mode 

9 

al-characters 


722 

11 

Link Status 

1 

al-characters 


723 

12-31 

Modification time 

20 

digits (with possible decimal point) 

2 

724 

32-51 

Creation time 

20 

digits (with possible decimal point) 

2 

725 

52-71 

Access time 

20 

digits (with possible decimal point) 

2 

726 

72-91 

File Size 

20 

digits 

1 

727 

92- 

File Name 


Alternate character set 

1 


728 File Type 

729 This is the single character as follows: 

730 - Regular file 

731 c Character special file 

732 b Block special file 
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733 

734 

735 

736 

737 

738 

739 

740 

741 

742 

743 

744 

745 

746 

747 

748 

749 

750 

751 

752 

753 

754 

755 

756 

757 

758 

759 

760 

761 

762 

763 

764 

765 

766 

767 

768 

769 
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d Directory 

p FIFO special file 

h High-performance file 

1 Symbolic link 

A- Z Reserved for implementations 

other Reserved for future standardization. 

The interpretation of the FIF and FDF for each of these file types shall be as 
specified below. 

File Mode 

The file protections shall consist of nine characters, presented as three groups of 
three characters each: 

<owner permissions> Permissions for the file owner class. 

<group permissions> Permissions for the file group class. 

<other permissions> Permissions for the file other class. 

Each field shall have three character positions: 

(1) If r, the file is readable; if-, it is not readable. 

(2) If w, the file is writable; if-, it is not writable. 

(3) The first of the following that applies: 

S If in <owner permissions>, the file is not executable and set- 
user-ID mode is set. If in <group permissions>, the file is not 
executable and set-group-ID mode is set. 

s If in <owner permissions>, the file is executable and set-user-ID 
mode is set. If in <group permissions>, the file is executable 
and set-group-ID mode is set. 

T If in <other permissions>, the file is executable and an 
unspecified concept of shared-executable is applied to the file. 
It is implementation defined whether such a mode is recorded. 
It is implementation defined what action, if any, beyond setting 
the the other-execute mode, is performed when T is found in 
this position in an archive. 

x The file is executable or the directory is searchable. 

None of the attributes of S, s, T, or x applies. 

Implementations may add other characters to this list for the third char¬ 
acter position. Such additions shall, however, be recorded in lowercase if 
the file is executable or searchable, and in uppercase if it is not. It is 
implementation defined whether, when such an extension is found when 
restoring an archive, any action beyond setting the group-execute mode 
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770 according to the case of the character occurs. 

771 DT: This is a fairly conservative approach to all this; given that this is new work, 

772 should the suid, sgid, and sticky hits be expressed separately ? 

773 Link Status 

774 This field indicates whether the file is a link or not. An ordinary file entry is indi- 

775 cated for the first (or only) entry in the archive for that file. Subsequent entries 

776 for additional links to that file shall indicate whether a link with or without data 

777 is recorded. The pax -o linkdata controls whether data is recorded; by default, l 

778 this linked data is not recorded. l 

779 When a link, with or without data, is recorded, a record containing the target of 

780 the link, recorded in the alternate character set, shall immediately follow the FIF 

781 File Group record, and preceding any information specific to the file type. For full 

782 portability, the length of the target shall not exceed {_POSIX_PATFl_MAX} octets. 

783 If the target of the link was restored by pax during the same invocation, then a l 

784 link to the target shall be created and the FDF associated with the link entry shall 

785 be ignored. If the link cannot be created, an error shall be reported and the link 

786 ignored. 

787 If a file was not restored during the same run the following actions shall be taken: 


788 

789 

790 


File Type Does Not 

Require Data (Including 
Zero Length) 

File Type Requires 
Data 

791 

Data present 

see 4.48.7.7 

restore 

792 

Data absent 

restore 

ignore entry 

793 


log 

log error 


794 A link with data shall be recorded with the File Size found at the time that 

795 specific link was recorded. If the length is found to be different from the length as 

796 recorded for a previous link, that fact shall be logged. 

797 A link without data shall have the File Size as found at the time the specific link 

798 was recorded, but no FDF shall be recorded for that file. 

799 The link type information is recorded as the single character as specified as fol- 

800 lows: 

801 
802 

803 

804 

805 
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806 File Modification, Access, and Creation Times 

807 These are the decimal representation of these times, as seconds since the Epoch. 2 

808 If a period (.) decimal point character is present, the digits to the right of the point 2 

809 shall represent the units of an implementation-defined subsecond timing granu- 2 

810 larity, which shall be ignored by implementations not supporting these units. 2 

811 The access and modification times shall be restored if the process has the 

812 appropriate privilege required to do so. 

813 File Size 

814 For all file types except those noted below, this is the size of the file, in octets, that 

815 is recorded on the media as the FDF; if the size of the file on the originating sys- 

816 tern should change during recording of the file, the file on the archive shall be 

817 truncated or padding of octets containing zeroes added as required to assure that 

818 the exact number of octets specified is actually recorded. 

819 Name 

820 The rest of the record shall consist of the Name, which shall be recorded in the 

821 alternate character set. No padding of Name shall occur, so that the length of 

822 Name can be calculated from the record length. The pax utility shall translate 1 

823 the Name in an implementation-defined manner to be the name of the file on the 1 

824 receiving system. HLJ: That needs work. In no case shall a file name that is not 1 

825 supported on the receiving system, or that cannot be subsequently accessed, be 

826 created. The length shall not exceed {_POSIX_PATFI_MAX} without agreement 

827 between the originator and the recipient that this can occur. 

828 4.48.7.6.4.2 FIF File Owner Record 1 

829 This shall be the name of the owner of the file as found in the user database on 

830 the originating system, represented in the alternate character set. The (variable- 

831 length) record shall consist solely of the the file owner name, with no padding. A 

832 zero-length record shall be recorded if the implementation creating the format 

833 does not support ownership on this file type. If a zero length owner is encoun- 

834 tered, it shall be treated as if the entry could not be found in the data base. 

835 After an implementation-defined translation to the character set of the receiving 

836 system, the File Owner name shall be used as the name of the owner of the file. If 

837 the same name appears in the user database of the receiving system (without 

838 truncation of either name), and if pax has the appropriate permission to do so, it 1 

839 shall set the owner-ID of the file it is restoring to be the corresponding user-ID. If 

840 the owner name does not appear in the user database of the receiving system, the 

841 file shall be created with the ownership of the user running pax, and the name 1 

842 that was not found shall be logged. 

843 If the implementation does not support ownership on the file type being restored, 

844 the owner information may be ignored. 
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845 4.48.7.6.4.3 FIF File Group Record l 

846 This shall be treated in the same way as the file owner entry except that the 

847 group database shall be consulted, and the file group owner set where appropri- 

848 ate. 

849 4.48.7.6.4.4 File-type Dependent Information 

850 The next several records in the FIF vary depending on the File Type recorded in 

851 the first record. The following subclauses describe these additional record types l 

852 and the interpretation of certain of the fields in the preceding records. 

853 Regular Files 

854 No File-type Dependent Information is recorded. The File Size is interpreted as 

855 the number of octets found in the FDF, except that the FDF shall be omitted if the 2 

856 file size is zero. 

857 Block or Character Special Files 

858 The file size in the first FIF record shall be zero, and no FDF shall be recorded. 

859 BP Field Name L Content 

860 1-15 System Identifier 15 al-characters 

86 1 16- Device Specification — al-characters 

862 System Identifier 

863 When written by pax, this field shall contain an implementation-defined value l 

864 representing the name of the implementation, the model, and submodel numbers 

865 sufficient to distinguish it from similar implementations that use a different 

866 representation of the Device Specification field. If pax recognizes this field, it l 

867 shall restore the special file according to the information appearing in the Device 

868 Specification. If pax does not recognize the System Identifier, the content of the l 

869 FIF, including the Device Specification and System Identifier, shall be logged and l 

870 pax may otherwise ignore the archive entry. l 

871 Device Specification 

872 This field (of variable length) is unspecified by this standard, except that it shall 

873 contain information sufficient to create a file identical in function to the one writ- 

874 ten by pax, when restored on the same implementation on which it was written. 

875 Directories 

876 The information in a directory FIF shall be used to restore file ownership and per- 

877 missions only after pax has completed reading the archive contents for that direc- 2 

878 tory. The meaning of the file size field is implementation defined. If the imple- 

879 mentation has no special definition for this field, it shall be ignored. No FDF shall 

880 be recorded for this entry type. 
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881 FIFOs 

882 No additional records shall be written. The file size shall be ignored, and no FDF 

883 shall be recorded. 

884 Symbolic Links 

885 A single record consisting solely of the pathname of the target of the symbolic 

886 link, in the alternate character set, shall be recorded. For full portability, the 

887 length of the name shall not exceed {_POSIX_PATH_MAX} octets. The link shall be 

888 created whether or not the target of the link exists. 

889 The ownership and protection information recorded for a symbolic link may be 

890 ignored. 

891 If a symbolic link entry is encountered on a system that does not support symbolic 

892 links, it is implementation defined whether, and under what conditions, the link 

893 is translated to a hard link. This translation shall be logged giving both names. 

894 If the link is not restored, that fact shall be logged. 

895 High Performance Files 

896 HLJ: Help is solicited from P1003.4. 

897 High-performance files shall be restored as regular files if the implementation 

898 does not support the file type. In such a case, the information in the records 

899 which follow shall be logged. 

900 Zero or more of the following records shall be recorded to reflect the information 

901 required to represent the high-performance file’s characteristics. 

902 BP _ Field Name _ Xl Content 

903 1-10 Flag 10 HIGH-PERF: 

904 11- Parameter Specification — al-characters 1 

905 Other File Types 

906 For other, implementation-defined, file types, additional information records may 

907 be provided as specified below. If the File Size in the first FIF record is nonzero, 

908 and if the implementation does not recognize the file type, the subsequent FDF 

909 shall be restored as an ordinary file. 

910 NOTE: This implies that the File Size field of the FDF must be accurate for all file types provided as 

911 an extension. 

912 BP _ Field Name _ Xc Content 

913 1-10 Flag 10 a-characters 

914 11- Parameter Specification — unspecified 1 

915 The Flag may be any combination of a-characters except those that are specified 

916 by this standard to appear as the first ten octets of a FIF record. The remaining 

917 characters shall either be al-characters or in the alternate character set. If the 

918 record type is not recognized by the implementation, it shall be logged; 
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919 translation from the alternate character set shall not occur when a record is 

920 logged. 

921 4.48.7.6.5 Security Records l 

922 Following the last file-type specific record, additional records of the following for- 

923 mat may be recorded. 

924 HLJ: Help from 1003.6 is solicited. 


925 

BP 

Field Name L 

Content 


926 

1-10 

Flag 10 

SECURITY: <space> 

2 

927 

11- 

Security Specification 

unspecified 

1 

928 

On systems that do not implement security extensions, these records may be 

2 

929 

ignored or logged. 




930 

4.48.7.6.6 Other FIF Information 



931 

For all file types. 

, additional information records may be provided as specified 


932 

below. 




933 

BP 

Field Name 

L Content 


934 

1-10 

Flag 

10 a-characters 


935 

11- 

Parameter Specification 

unspecified 

1 


936 The Flag may be any combination of a-characters except those that are specified 

937 by this standard to appear as the first ten octets of a FIF record. The remaining 

938 characters shall either be al-characters or in the alternate character set. If the 

939 record type is not recognized by the implementation, it shall be logged; transla- 

940 tion from the alternate character set shall not occur when a record is logged. 

941 4.48.7.6.7 The FIF EOF1 Label 

942 The EOF1 Record shall be identical to the HDR1 record recorded for the FIF, 


943 

except in the following fields. 



944 

BP 

Field Name 

L P 

Content 

945 

1-3 

Label Identifier 

3 

EOF 

946 

55-60 

Block Count 

6 

<space>, digits 


947 4.48.7.6.7.1 Block Count 


948 This field shall be as specified in ISO 1001 {9}. If the actual block count exceeds 

949 the maximum value of a six-digit decimal number, it shall be recorded modulo 2 

950 1000 000. 2 

951 4.48.7.6.8 The FIF EOF2-9 and UTL1-9 Labels 

952 These records are optional, but if present shall be recorded in accordance with 

953 ISO 1001. They shall be ignored on input, and it is implementation defined as to l 

954 whether they are written in output. l 
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955 4.48.7.7 The File Data File 

956 The file data file is optional, and when present shall contain the data contained in 

957 the file. If this file is omitted when it is expected, an empty file of the specified 

958 type shall be created, and an error logged. If a file of this type is found when it is 

959 not expected, the name from the HDR1 record shall be used as the name of a file 

960 containing the data found in the FDF, in an implementation-defined directory. An 

961 error shall be logged. 

962 4.48.7.7.1 The FDF HDR1 Label 


963 

BP 

Field Name 

L 

P 

Content 


964 

1-3 

Label Identifier 

3 


HDR 


965 

4 

Label Number 

1 


1 


966 

5-21 

File Identifier 

17 

* 

a-characters 


967 

22-27 

File Set Identifier 

6 


a-characters 


968 

28-31 

File Section Number 

4 


digits 


969 

32-35 

File Sequence Number 

4 


digits 


970 

36-39 

Generation Number 

4 


digits 


971 

40-41 

Generation Version Number 

2 


digits 


972 

42-47 

Creation Date 

6 

* 

See 4.48.7.7.1.7 

1 

973 

48-53 

Expiration Date 

6 

* 

See 4.48.7.7.1.8 

3 

974 

54 

File Accessibility 

1 


a-characters 


975 

55-60 

Block Count 

6 


000000 

1 

976 

61-73 

Implementation Identification 

13 

* 

<space>s 

3 

977 

74-78 

POSIX Identification 

5 

* 

POSIX 

3 

978 

79 

POSIX Version 

1 

* 

1 

3 

979 

80 

FDF Identifier 

1 

* 

D 

3 

980 

74-80 

(Reserved for future POSIX standardization) 7 


<space>s 



98i 4.48.7.7.1.1 File Identifier 


982 This shall be the name of the FDF file. It shall be derived from the name of the 

983 POSIX file being recorded as the filename (not pathname) of the file being 

984 recorded, folded to a-characters. 

985 4.48.7.7.1.2 File Set Identifier 

986 This field shall be ignored. 

987 4.48.7.7.1.3 File Section Number 

988 This field shall be as specified in ISO 1001 {9}. 

989 4.48.7.7.1.4 File Sequence Number 

990 This field shall be ignored. 
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991 4.48.7.7.1.5 Generation Number 

992 This field shall be ignored. 

993 4.48.7.7.1.6 Generation Version Number 

994 This field shall be ignored. 

995 4.48.7.7.1.7 Creation Date 

996 This shall be the representation of the POSIX. 1 {8} st_ctime field of the file con- 

997 verted to a Julian day, according to the time zone active at the time pax was run. l 

998 4.48.7.7.1.8 Expiration Date 

999 This shall be the same value as the creation date; see 4.48.7.7.1.7. 3 

1000 4.48.7.7.1.9 File Accessibility 

1001 HLJ: Help from 1003.6 is solicited. 

1002 The content of this field may be any permissible value; pax shall ignore this field. l 

1003 4.48.7.7.1.10 Block Count 

1004 This field shall be as specified in ISO 1001 {9}. 


1005 4.48.7.7.2 Second FDF File Header Label (HDR2) 


1006 

BP 

Field Name 

L 

P 

Content 

1007 

1-3 

Label Identifier 

3 


HDR 

1008 

4 

Label Number 

1 


2 

1009 

5 

Record Format 

1 

* 

F 

1010 

6-10 

Block Length 

5 

* 

16384 

1011 

11-15 

Record Length 

5 

* 

00000 

1012 

16-20 

Standards Body 

5 

* 

a-characters 

1013 

21-25 

Number 

5 

* 

a-characters 

1014 

26-30 

Variant 

5 

* 

a-characters 

1015 

31-34 

Revision 

4 

* 

a-characters 

1016 

35-50 

(Reserved for Implementation) 

16 


not specified 

1017 

51-52 

Offset Length 

2 


00 

1018 

53-80 

(Reserved for Standard) 

28 


<space>s 


1019 4.48.7.7.2.1 Standards Body, Number, Variant, Revision 

1020 These fields record the same information, and are encoded in the same way, as 

1021 the corresponding fields in the VOL2 Header Label. They specify the alternate 

1022 character set to be used in the FDF file for those fields permitted to be in the alter- 

1023 nate character set. If all these fields are spaces, instead of indicating ISO/IEC 646 

1024 {1} IRV, the alternate character set specified in the VOL2 label shall be used. If 

1025 the Standards Body field is “binary”, the data recorded shall not be translated 

1026 from the alternate character set. 
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1027 4.48.7.7.2.2 Record Format 

1028 Data is always recorded as one record per block. The data from the file is 

1029 recorded exactly as it comes from the file. 

1030 4.48.7.7.2.3 Block Length 

1031 This is the constant 16 384. 1 

1032 4.48.7.7.2.4 Record Length 

1033 This shall be zeroes. 

1034 4.48.7.7.2.5 Offset Length 

1035 This field shall contain zeroes. 2 

1036 4.48.7.7.3 Additional FDF File Header Labels (HDR3-9 and UHL?) 2 

1037 These records are not permitted for the FDF. On media with tape marks, if 

1038 present, they shall be ignored. 

1039 4.48.7.7.4 FDF Data 

1040 The content of the file shall be recorded in logical blocks of 16 384 octets in length. 2 

1041 The last block may be truncated to the actual length. 

1042 4.48.7.7.5 The FDF EOF1 Label 

1043 The EOF1 Record shall be identical to the HDR1 record recorded for the FIF, 

1044 except in the following fields. 

1045 BP Field Name L P Content 

1046 1-3 Label Identifier 3 eof 

1047 55-60 Block Count 6 <space>, digits 

1048 4.48.7.7.5.1 Block Count 

1049 This field shall be as specified in ISO 1001 {9}. If the actual block count exceeds 

1050 the maximum value of a six-digit decimal number, it shall be recorded modulo 2 

1051 1000 000. 2 

1052 4.48.7.7.6 The FDF EOF2-9 and UTL1-9 Labels 

1053 These records are optional, but if present shall be recorded in accordance with 

1054 ISO 1001 {9}. They shall be ignored on input, and it is implementation defined as l 

1055 to whether they are written in output. l 
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1056 4.48.7.7.7 Other labels 

1057 Other labels (including the EOV labels) shall be written in accordance with 

1058 ISO 1001 {9}. 

1059 4.48.7.8 Rationale— pax Interchange Format. (This subclause is not a part of 

1060 P1003.2b) 

1061 This is a data interchange format for POSIX that meets the requirements of inter- 

1062 change that were discussed in the debates on whether the USTAR or CPIO formats 

1063 were the appropriate vehicles for such interchange. It is also intended to meet 

1064 the known additional requirements developed since those debates, and be extensi- 

1065 ble, in an upward and downward compatible way, to allow future file types. Addi- 

1066 tionally, it meets the requirements of ISO 1001 {9}, which is equivalent to ANSI 

1067 X3.27-1987, when certain additional constraints are met. (X3.27 is an old stan- 

1068 dard, having been around in some form since at least the late 1960s. The 1987 

1069 revision appears to be the fourth revision.) This allows a minimal, but useful, 

1070 level of interchange to systems conforming to ISO 1001 but not to this standard. 

1071 Since pax (as well as the other POSIX.2 utilities) is not required by the standard 3 

1072 to be implemented portably, this interchange format should allow a useful inter- 3 

1073 change of data by systems where the tape operations are managed by the operat- 3 

1074 ing system as well as by systems where pax writes directly to the media. The 3 

1075 implementation of pax on the former will usually consist of requests for the 3 

1076 “header” and “user data” parts of the archive from the system (the system itself 3 

1077 reading the headers and providing the information to pax). 3 

1078 The terminology and concepts taken from ISO 1001 that are needed for under- 

1079 standing this proposal are defined informally here, where the formal definition 

1080 should be taken from the standard itself. Such terms are flagged the first time 

1081 they are used with “(1001),” and excerpts from that standard are quoted. 

1082 In a few instances, definitions taken directly from ISO 1001 {9} are included in 

1083 this rationale. 

1084 This format is intended for interchange, not for backup on a single (family of) sys- 

1085 terns. It is not as densely packed as might be obtained for backup, and contains 

1086 information as coded characters that for backup could be coded in binary. The 

1087 whole issue of identification of character sets is probably unnecessary for backup. 

1088 Note that there is no requirement on the format of the log, although constraints 

1089 on the content are mentioned. The log is intended for human use to recover from 

1090 problems found during restoring the archive. 

1091 “Octet” is chosen both to emphasize the 8-bit nature of this interface, and to avoid 

1092 confusion with the meaning of “byte” as used in most of the rest of this standard. l 

1093 The requirements on restoring from an archive are slightly different from the his- 

1094 torical wording, allowing for nonmonolithic privilege to bring forward as much as 

1095 possible. In particular, attributes such as “high performance file” might be 

1096 broadly but not universally granted while set-user-ID or chown() might be much 

1097 more restricted. There is no implication in this standard that the security 
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1098 information be honored after it is restored to the file hierarchy, in spite of what 

1099 might be improperly inferred by the silence on that topic. That is a topic for 
noo another standard. 

noi If the implementation can make use of further extensions in label records (or if 

1102 they are automatically generated by some systems) it is permissible use them 

1103 with an option. This may prove particularly useful for tapes generated on “label- 

1104 smart” systems. 

1105 The character set folding is not ideal, but to be consistent with ISO 1001 {9}, it is 

1106 required for fields appearing in the header. Note that such fields are only mean- 

1107 ingful when the format is not read on a POSIX system or in the case of error, so no 
nos crucial data is lost. 

1109 Requiring tape marks first of all is required by ISO 1001 {9} for the tape formats 

1110 above. It also makes recovering a damaged tape much easier. Because media 

1111 such as regular files do not have the ability to record such things, they are not 

1112 strictly required for other media, but they are recommended where it is possible. 

1113 Note also that this implies that for tape and tape-like devices, a label is identi- 

1114 cally a block (other than possible padding in the block). This is also intended 

1115 here. For devices that do not have a block structure like this, then a stream 

1116 model applies. 

1117 ISO 1001 {9} says that there is either only one file section, or if the file will not fit 

1118 on the current volume (either because it ran out of space along the way, or 

1119 because the file is too big for one volume) that the second section follow the first 

1120 on the next volume, and that no other files intervene until the whole file is 

1121 recorded. (If the file is huge, there may be many sections, but each must use the 

1122 whole volume until the last.) Because tape marks are “out of band,” it is safe to 

1123 split data across several volumes like this. 

1124 The first form of recording on media other than magnetic tape is specifically 

1125 addressing either stream devices or recording on an “ordinary file.” The second 

1126 addresses devices such as sectored disks. Note that without a tape mark or 

1127 equivalent out-of-band indicator, when dealing with files that span multiple phy- 

1128 sical volumes, that it is impossible to tell where the data ends and any label 

1129 records begin. When tape marks are present, this is feasible, and labels are 

1130 required. 

1131 Implementors should note that implementations that refuse to allow writing at 

1132 least label records after the end-of-tape reflector spot is detected may not be able 

1133 to conform to this standard (or to ISO 1001 {9}). Historical UNIX systems have not 

1134 handled the detection of the reflector spot consistent with historical usage in 

1135 other “tape-smart” systems. Implementations must be able to read data after the 

1136 end-of-tape reflector spot because other implementations may have written past 

1137 that point. An implementation is free to back up and write the end-of-tape infor¬ 
ms mation after detecting the reflector spot, while holding the previously written 

1139 information in memory for the next volume. However, given the requirement to 

1140 read past the reflector spot, that may not be worthwhile to implement. 
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1141 

1142 

1143 

1144 

1145 

1146 

1147 

1148 

1149 

1150 

1151 

1152 

1153 

1154 

1155 

1156 

1157 

1158 

1159 

1160 
1161 
1162 

1163 

1164 

1165 

1166 

1167 

1168 

1169 

1170 

1171 

1172 

1173 

1174 

1175 

1176 

1177 

1178 

1179 

1180 
1181 
1182 

1183 

1184 


HLJ: These following paragraphs on multivolume archives need work. l 

Although it is not required by POSIX. 1, implementations of the format-reading 
and -creating utility, upon reading logical end-of-file, may check to see if an error 
channel is open to a controlling terminal. The utility then produces a message 
requesting a new medium to be made available. The utility waits for a new 
medium to be made available by attempting to read a message to restart from the 
controlling terminal. In all cases, the communication with the controlling termi¬ 
nal is performed in an implementation-defined manner. 

The handling of multivolume archives historically has been inconsistent. The 
1988 and 1990 versions of POSIX.l attempted to clarify this in rationale similar to 
that below. For this new format, the issues of multivolume archives are 
addressed more precisely. However, for magnetic tape, this needs further 
clarification because ISO 1001 presumes behavior that many historical systems 
similar to POSIX have not performed properly in the past. 

POSIX. 1 is intended to be interpreted such that each byte of the format is 
represented on the media exactly once. 

In some current implementations, it is not deterministic whether encountering 
the end-of-medium reflector foil on magnetic tape during a write will yield an 
error during a subsequent read () of that record, or even if that record is actually 
recorded on the tape. It is also possible that read{) will encounter the end-of- 
medium when end-of-medium was not encountered when the data was written. 
This has to do with conditions where the end of (magnetic) record is in such a 
position that the reflector foil is on the verge of being detected by the sensor and 
is detected (nondeterministically) during one operation and not on a later one. 

An implementation of the format-creating utility must assure when it writes a 
record that the data appears on the tape exactly once, and is properly followed by 
the trailer labels required by ISO 1001. This implies that the program and the 
tape driver work in concert. An implementation of the format-reading utility 
must assure that an error in a boundary condition described above will not cause 
loss of data, and that trailer labels will be properly interpreted. 

The general consensus was that the following would be considered as correct 
operation of a tape driver when end-of-medium is detected: 

(1) During writing, either: 

(a) The record where the reflector spot was detected is backspaced over 
by the driver so that the trailing tape mark and labels that must be 
written will overwrite the old record. (It should be noted that in 
most cases, the trailing labels will be much longer than the original 
record due to the number of interrecord gaps required.) Writing the 
labels and tape marks should not yield an end-of-medium condition. 

(b) The condition is reported as an error on the write () following the 
one where the end-of-medium is detected (the one where the end- 
of-medium is actually detected completing successfully). No data 
will be actually transferred on the write () reporting the error, but 
label records can be written. Writing the tape mark, and writing 
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1185 

1186 

1187 

1188 

1189 

1190 

1191 

1192 

1193 

1194 

1195 

1196 

1197 

1198 

1199 

1200 

1201 

1202 

1203 

1204 

1205 

1206 

1207 

1208 

1209 

1210 

1211 

1212 

1213 

1214 

1215 

1216 


any subsequent records, should not yield any end-of-medium condi¬ 
tions. 

(2) During reading, the end-of-medium indicator is simply ignored, presum¬ 
ing that (end-of-file) labels will be recorded on the magnetic medium and 
that the reflector foil was advisory only to the write (). 

Systems where these conditions are not met by the tape driver should assure that 
the format-creating and -reading utilities assure proper representation and 
interpretations of the files on the media in a way consistent with the above recom¬ 
mendations. 

The typical failures on systems that do not meet the above conditions are either: 

(1) To leave the record written when the end-of-medium is encountered on 
the tape, but to report that it was not written, and possibly not write the 
trailing labels. The format-creating utility would then rewrite the failed 
record on the next volume. The format-reading utility could see the 
record twice if the end-of-medium is not sensed during the read opera¬ 
tions. 

(2) The write () occurs uneventfully, but the reacii) senses the error and does 
not actually see the data, causing a record to be omitted, and trailing 
labels are not seen. 

Nothing in POSIX.l requires that end-of-medium be determined by anything on 
the medium itself (for example, a predetermined maximum size would be an 
acceptable solution for the format-creating utility). The format-reading utility 
must be able to read() tapes written by machines that do use the whole medium, 
however. 

On media where end-of-medium and end-of-file are reliably coincident, such as 
disks, end-of-medium and end-of-file can be treated as synonyms. 

Note that partial physical records [corresponding to a single write()] can be writ¬ 
ten on some media, but that only full physical records will actually be written to 
magnetic tape, given the manner in which the tape operates. 

There is wording to specifically to disallow using the “no tape mark” option on 
magnetic tape, even by agreement, and have it considered as conforming to this 
standard. 
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1217 A tape that is a single volume looks (roughly) like this in ISO 1001 {9}: 


1218 

1219 

1220 
1221 
1222 

1223 

1224 

1225 

1226 
1227 


Beginning of Volume Label Group. (VOL? and UVL?) 

( 

Beginning of File Label Group. (HDR? and UHL?) 
tape mark 
file data 
tape mark 

End of File Label Group. (EOF? and UTL?) 
tape mark 

)* 

tape mark 


1228 NOTE: (“?’ and V are used in the sense of regular expressions.) 


1229 When the file data spans the end of volume, the End of File Label Group 

1230 becomes an “End of Section Label Group” (EOV? and UTL?), and no further 

1231 data can be recorded on the volume. The next segment of the file must be 

1232 at the beginning of the next volume, and there are requirements about the 

1233 consistency of many of the fields between the File Header Label Group for 

1234 each Section. 

1235 ISO 1001 {9}: A sequence of one or more labels of the same type, recorded 

1236 in consecutive blocks shall be a label set of that type. All labels in a set 

1237 shall be numbered consecutively starting from 1, except those labels in 

1238 User file Header and User File Trailer Label Sets. 

1239 ISO 1001 {9}: The label in User File Header and User File Trailer Label 

1240 Sets may be identified in any order and may contain duplicate identifiers 

1241 within a set. 

1242 Note that this format yields a double tape mark at the end of the tape. 

1243 Obviously, in the case of other media, the single volume requirement 

1244 assures that an End of Section Label Group would never be used. 
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1245 A tape that is a single volume will look (roughly) like this in the pax Data Inter- l 

1246 change Format: l 

1247 Beginning of Volume Label Group (VOL1, VOL?, and UVL?) l 

1248 ( 1 

1249 File Information File Label Group. (HDR1, HDR2, and UHL?) 2 

1250 tape mark (optional, based on media) l 

1251 File Information File data l 

1252 ( 1 

1253 4-digit record size l 

1254 FIF Filename Record l 

1255 4-digit record size l 

1256 FIF Owner Record l 

1257 4-digit record size l 

1258 FIF Group Record l 

1259 4-digit record size l 

1260 FIF Type Dependent Information l 

1261 Optional records 1 

1262 ( 1 

1263 4-digit record size l 

1264 FIF Security record (optional) l 

1265 4-digit record size l 

1266 FIF Information record (optional) l 

1267 ) 1 

1268 ) 1 

1269 tape mark (optional) l 

1270 End of File Information File Label Group (EOF1, EOF?, and UTL?) l 

1271 tape mark (optional) l 

1272 File Data File Label Group (HDR1, HDR2) (if data expected, l 

1273 else no File Data File) 1 

1274 tape mark (optional) l 

1275 Data in 16384-octet “logical” blocks 2 

1276 tape mark (optional) 1 

1277 End of File Data File Label Group (EOF1, EOF?, and UTL?) 1 

1278 (becomes End Of Volume Group (EOV? and UTL?) at end of 1 

1279 Volume or Section) 1 

1280 tape mark (optional) 1 

1281 )* 1 

1282 tape mark (optional) 1 

1283 NOTE: (‘?’ and are used in the sense of shell pattern matching.) 1 

1284 It is possible that some implementations will provide a mechanism for setting the 

1285 Volume Identifier field independent from the archiver, possibly as part of a more 

1286 general handling of labeled tapes. Note that the format creating utility may have 

1287 to deal with an interface that assures that the volume identification is retained on 

1288 the tape when it is rewritten. The POSIX Identifier and version fields are not 

1289 intended to be required for general labeled tapes. 
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1290 VOL2 is not specified at all beyond its possible existence in ISO 1001 {9}. Addi- 

1291 tional labeling information may be stored there. 

1292 Only a limited number of character set standards can actually be permitted for 

1293 maximal interchange. Any character set is of course possible by prior agreement. 

1294 It has been suggested that EBCDIC be listed. It is not clear whether it is a formal 

1295 standard; it is omitted. Formal standards, and then only those with reasonably 

1296 large followings, can be included here, simply as a matter of practicality. 

1297 The notation used for an ISO/IEC 646 {1} National Usage variant is appropriate 

1298 material for a National Profile. 

1299 The requirement that translation be able to be suppressed permits mixing binary 

1300 and character data in a single archive, extracting both, and then translating only 

1301 the character files. (The character set “binary” in the FDF is similar; this permits 

1302 such data to be extracted in the absence of the preplanning needed to use binary.) 

1303 (The tr utility will not do because not all the translations are 1:1.) The utility 

1304 could be popen()-e d to simplify the utility implementation. 

1305 ISO 1001 {9} contains the following note: The File Identifier field of a file within a 

1306 file set is permitted to be the same as that of other files in the file set. Note that 

1307 this is not the pathname of the file, but rather again exists for the purposes of 

1308 non-POSIX systems. 

1309 ISO 1001 {9}: The File Section Number field shall specify the ordinal number of 

1310 the file section as a four-digit decimal number. The characters in this field shall 

1311 be digits. 

1312 The format of dates in the Creation and Expiration Date fields means nothing to 

1313 POSIX, but might be useful to other systems. In ISO 1001 {9} they are Julian 

1314 dates, accurate only to the day. The coding of the Expiration Date is taken to 

1315 mean obsolete data by ISO 1001 {9}. This value was selected because certain 2 

1316 operating systems prevent overwriting of the tape if the date has not past. 2 

1317 ISO 1001 {9}: The Block Count field shall specify a constant value. The charac- 

1318 ters in this field shall be zeroes. 

1319 (Block count is used on the EOF1 record, which is the same format as HDR1.) 

1320 The Record Format field allows for several long records (such as the pathname) 

1321 without introducing any complexity beyond that already in ISO 1001. 

1322 Note that the four-octet length field is explicitly required even when the record is 

1323 put on nontape media. In addition to specifying length, they also serve to 

1324 separate header labels from the content. 

1325 Headers can be distinguished from the data because the first record of the actual 

1326 file will be a variable-length record, which must begin with four digits. 

1327 Links are recorded in this fashion described here because a link can be to any file 

1328 type. It is desirable in general to be able to selectively restore part of an archive, 

1329 and restore all the files completely. If the data is not associated with each link, it 

1330 is not possible to do this. However, the data associated with a file can be large, 

1331 and when selective restoration is not needed, this can be a significant burden. 
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1332 The archive is structured so that files that have no associated data can always be 

1333 restored by the name of any linkname of any link, and the user may choose 

1334 whether data is recorded with each instance of a file that contains data. Although 

1335 not required of an implementation of pax, the format permits mixing of both types l 

1336 of links in a single archive; this can be done for special needs, and pax is expected l 

1337 to properly interpret such archives on input. l 

1338 Note that device/i-number labeling of files is not carried forward from us tar and 

1339 cpio; rather, it works strictly on a symbolic name basis. This is intentional 

1340 because device/i-number links could break if files span file systems that did not 

1341 used to do so, and because to repair problems it is more useful to have both 

1342 names. 

1343 The file protection modes are those conventionally used by the 1 s utility. This is 

1344 extended beyond the usage in 1003.2 to support the “shared text” or “sticky” bit. 

1345 It is intended that the conformance document should not document anything 

1346 beyond the existence of and support of such a mode. Further extensions are 

1347 expected to these bits, particularly with overloading the set-user-ID and set- 

1348 group-ID flags. 

1349 Creation time (actually i-node modification time) is for information only, as it is 

1350 not possible to effectively change it portably. Nothing is intended to prevent a 

1351 nonportable implementation of the utility from restoring the value. Even though l 

1352 implementation capabilities are moving toward the necessity of finer granularities l 

1353 than seconds, the times here are in seconds since the Epoch since POSIX.l {8} l 

1354 states them that way. The storage space allocated takes into account that this l 

1355 may change. l 

1356 Note that the format used for a file name allows for slightly less than 10 000 

1357 octets of pathname. This is well above any current practical limit known. 

1358 There is a potential issue of name registration for systems, but it is unlikely to be 

1359 a problem as vendors do try to keep their systems clearly identifiable. Note that 

1360 this permits someone to write a special file on one system and restore it on an 

1361 incompatible system by interpreting the meaning in some way. 

1362 Delaying restoration of the file ownership and permissions for a directory assures 

1363 that pax will be able to continue to write entries in the directory. The behavior of l 

1364 the file size field is implementation defined to permit, but not endorse, a current 

1365 USTAR behavior. 

1366 The explicit permission for extension through the use of additional FIF records is l 

1367 included because historically archive formats have not been easily extended to 

1368 allow new information. It is expected that both implementation specific exten- 

1369 sions and future standards will use this mechanism. The Flag field was chosen to 

1370 be sufficiently long to allow such extensions without fear of name conflict. 

1371 Because it is a known extension currently under development, security : is expli- 

1372 citly reserved. 

1373 ISO 1001 {9}: Within a Labeled-Sequence the content of the fields of this label 

1374 shall be identical with the contents of the corresponding fields in the First File 

1375 Header Label, except for the following fields. 
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1376 ISO 1001 {9}: “[The Block Count] field shall specify, as a six-digit decimal 

1377 number, the number of blocks in which the file section is recorded.” 

1378 If an unexpected FDF is found, it is intended that the data is put where it can be 

1379 examined later; the only candidate name (other than a synthetic one) is the one 

1380 from the HDR1. The directory should either be the current working directory, or a 

1381 specified “errors” directory if the utility provides one. 

1382 The description of record format seems the best approximation to POSIX’s l 

1383 unstructured files. No attempt to organize this for non-POSIX systems is made for 

1384 this archive format. 

1385 Because of the unstructured nature of POSIX files, the maximum record length is 

1386 not specified. In ISO 1001 {9}, this is zero, indicating unspecified length. 

1387 Because there is no way to tell how many HDR3-9 and UHL? labels there are in 2 

1388 the absence of tape marks, they are not permitted because it becomes impossible 

1389 to detect the start of the actual data. If they are present on magnetic tape any- 

1390 way, they are ignored simply to allow fail-soft when tapes approximately in this 

1391 format are written on some systems. 

1392 Although the description of FDF Data states that the last block may be truncated 

1393 to the actual length, note the statements in General Requirements about padding. 
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1394 4.48.8 Extended Description — cpio Interchange Format 

1395 HLJ: This is the text adopted from 1003.1LIS Draft 1. It has been left generally l 

1396 unmodified as a working group exercise. l 

1397 The octet-oriented cpio archive format shall be a series of entries, each compris- 

1398 ing a header that describes the file, the name of the file, and then the contents of 

1399 the file. 

1400 An archive may be recorded as a series of fixed-size blocks of octets. This blocking 

1401 shall be used only to make physical I/O more efficient. The last group of blocks 

1402 always shall be at the full size. 

1403 For the octet-oriented cpio archive format, the individual entry information shall 

1404 be in the order indicated and described by Table 4-100. 


1405 Table 4-100 - Octet-Oriented cpio Archive Entry l 

1406 _ 


1407 


Header 


1 

1408 

Field Name 

Length (in octets) 

Interpreted as 

1 

1409 

cjnagic 

6 

Octal number 

1 

1410 

c_dev 

6 

Octal number 

1 

1411 

c_ino 

6 

Octal number 

1 

1412 

cjnode 

6 

Octal number 

1 

1413 

cjuid 

6 

Octal number 

1 

1414 

c_gid 

6 

Octal number 

1 

1415 

c_nlink 

6 

Octal number 

1 

1416 

c_rdev 

6 

Octal number 

1 

1417 

cjntime 

11 

Octal number 

1 

1418 

cjiamesize 

6 

Octal number 

1 

1419 

c Jilesize 

11 

Octal number 

1 

1420 


File Name 


1 

1421 

Field Name 

Length 

Interpreted as 

1 

1422 

cjiame 

c_namesize 

Pathname string 

1 

1423 


File Data 


1 

1424 

Field Name 

Length 

Interpreted as 

1 


1425 c Jiledata c Jilesize Data 1 

1426 _ 


1427 4.48.8.1 cpio Header 

1428 For each file in the archive, a header as defined previously shall be written. The 

1429 information in the header fields shall be written as streams of ISO/IEC 646 {1} 

1430 characters interpreted as octal numbers. The octal numbers shall be extended to 

1431 the necessary length by appending ISO/IEC 646 {1} IRV zeros at the most- 

1432 significant-digit end of the number; the result is written to the stream of octets 

1433 most-significant-digit first. The fields shall be interpreted as follows: 
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1434 

1435 

1436 

1437 

1438 

1439 

1440 

1441 

1442 

1443 

1444 

1445 

1446 

1447 

1448 

1449 

1450 

1451 

1452 

1453 

1454 

1455 

1456 

1457 

1458 

1459 

1460 

1461 

1462 

1463 

1464 

1465 

1466 

1467 

1468 

1469 

1470 

1471 

1472 

1473 
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cjnagic 

cjdev 

c_ino 


c_mode 


c_uid 

c_gid 

c_nlink 

c_rdev 


Shall identify the archive as being a transportable archive by con¬ 
taining the identifying value "070707". 


Shall contain values that uniquely identify the file within the 
archive (i.e., no files shall contain the same pair of cjdev and 
c_ino values unless they are links to the same file). The values 
shall be determined in an unspecified manner. 

Shall represent the following values of the file mode type: 


04 000 

setpser_idpn_exec 

02 000 

set_group_idjm_exec 

01 000 

<reserved> 

00 400 

ownerjread permission 

00 200 

ownerjwrite permission 

00 100 

owner_execpr_search permission 

00 040 

grouppead permission 

00 020 

group jwrite permission 

00 010 

group_execpr_search permission 

00 004 

otherpead permission 

00 002 

other jwrite permission 

00 001 

other_execprpear ch permission 

and the following values from the file_type_type: 

040 000 

Directory. 

010 000 

FIFO. 

0100 000 

Regular file. 

060 000 

Block special file. 

020 000 

Character special file. 

0110 000 

<reserved>. 

0120 000 

<reserved>. 

0140 000 

<reserved>. 


Directories, FIFOs, and regular files shall be supported on a sys¬ 
tem conforming to this standard; additional values defined previ¬ 
ously are reserved for compatibility with existing systems. Addi¬ 
tional file types may be supported; however, such files should not 
be written on archives intended for transport to portable systems. 

Shall contain the user ID of the owner. 

Shall contain the group ID of the group. 

Shall contain the number of links referencing the file at the time 
the archive was created. 

Shall contain implementation-defined information for character 
or block special files. 
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1474 

1475 

1476 

1477 

1478 

1479 

1480 

1481 

1482 

1483 

1484 

1485 

1486 

1487 

1488 

1489 

1490 

1491 

1492 

1493 

1494 

1495 

1496 

1497 

1498 

1499 

1500 

1501 

1502 

1503 

1504 

1505 

1506 

1507 

1508 

1509 

1510 

1511 

1512 


cjntime Shall contain the latest time of modification of the file at the time 
the archive was created. 

c_namesize Shall contain the length of the pathname, including the terminat¬ 
ing NUL character. 

c Jilesize Shall contain the length of the file in octets. This shall be the 
length of the data section following the header structure. 

4.48.8.2 cpio File Name 

The c_name field shall contain the pathname of the file. The length of this field in 
octets shall be the value of c_namesize. If a file name is found on the medium 
that would create an invalid pathname, the implementation shall define if the 
data from the file is stored on the file hierarchy and under what name it is stored. 

All characters shall be represented in ISO/IEC 646 {1} IRV. For maximum porta¬ 
bility between implementations, names should be selected from characters 
represented by the portable filename character set as octets with the most 
significant bit zero. If an implementation supports the use of characters outside 
the portable filename character set in names for files, users, and groups, one or 
more implementation-defined encodings of these characters shall be provided for 
interchange purposes. However, the format-reading utility shall never create file 
names on the local system that cannot be accessed via the procedures described 
previously in this standard. If a file name is found on the medium that would 
create an invalid file name, the implementation shall define if the data from the 
file is stored on the local file system and under what name it is stored. A format¬ 
reading utility may choose to ignore these files as long as it produces an error 
indicating that the file is being ignored. 

4.48.8.3 cpio File Data 

Following c_name, there shall be c Jilesize octets of data. Interpretation of such 
data shall occur in a manner dependent on the file. If c Jilesize is zero, no data 
shall be contained in c Jiledata. 

When restoring from an archive: 

— If the user does not have the appropriate privilege to create a file of the 
specified type, the format-interpreting utility shall ignore the entry and 
issue an error to the standard error output. 

— Only regular files have data to be restored. Presuming a regular file meets 
any selection criteria that might be imposed on the format-reading utility 
by the user, such data shall be restored. 

— If a user does not have appropriate privilege to set a particular mode flag, 
the flag shall be ignored. Some of the mode flags in the archive format are 
not mentioned elsewhere in this standard. If the implementation does not 
support those flags, they may be ignored. 
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1513 4.48.8.4 cpio Special Entries 

1514 FIFO special files, directories, and the trailer shall be recorded with c Jilesize 

1515 equal to zero. For other special files, c Jilesize is unspecified by this standard. 

1516 The header for the next file entry in the archive shall be written directly after the 

1517 last octet of the file entry preceding it. A header denoting the file name 

1518 “trailer! ! !” shall indicate the end of the archive; the contents of octets in the 

1519 last block of the archive following such a header are undefined. 

1520 4.48.8.5 Rationale. (This subclause is not a part of P1003.2b) 

1521 The part about appropriate privilege in cpio refers to an error on standard out- 

1522 put; tar does not say that. 

1523 The model for this format was the historical System V cpio -c data interchange 

1524 format. This model documents the portable version of cpio format and not the 

1525 binary version. It has the flexibility to transfer data of any type described within 

1526 the POSIX. 1 standard, yet is extensible to transfer data types specific to exten- 

1527 sions beyond POSIX. 1 (e.g., symbolic links or contiguous files). Because it 

1528 describes existing practice, there is no question of maintaining upward compati- 

1529 bility. 

1530 This subclause does not standardize behavior for the utility when the file type is 

1531 not understood or supported. It is useful for the utility to report to the user what- 

1532 ever action is taken in this case, though POSIX. 1 neither requires nor recommends 

1533 this. 

1534 4.48.8.5.1 cpio Header 

1535 There has been some concern that the size of the cjno field of the header is too 

1536 small to handle those systems that have very large i-node numbers. However, the 

1537 cjno field in the header is used strictly as a hard link resolution mechanism for 

1538 archives. It is not necessarily the same value as the i-node number of the file in 

1539 the location from which that file is extracted. 

1540 The name cjnagic is based on historical usage. 

1541 4.48.8.5.2 cpio File Name 

1542 For most historical implementations of the cpio utility, {PATH_MAX} octets can 

1543 be used to describe the pathname without the addition of any other header fields 

1544 (the NUL character would be included in this count). {PATH_MAX} is the 

1545 minimum value for pathname size, documented as 256 bytes in Section 2 . How- 

1546 ever, an implementation may use c_namesize to determine the exact length of the 

1547 pathname. With the current description of the cpio header, this pathname size 

1548 can be as large as a number that is described in six octal digits. 

1549 Three values are documented under the cjnode field values to provide for extensi- 

1550 bility for known file types: 
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1551 

1552 

1553 

1554 


0110 000 Reserved for contiguous files. The implementation may treat the 
rest of the information for this archive like a regular file. If this 
file type is undefined, the implementation may create the file as a 
regular file. 


1555 

1556 

1557 

1558 

1559 

1560 


0120 000 Reserved for files with symbolic links. The implementation may 
store the link name within the data portion of the file. If this 
type is undefined, the implementation may not know how to link 
this file or be able to understand the data section. The implemen¬ 
tation may decide to ignore this file type and output a warning 
message. 


1561 

1562 

1563 


0140 000 Reserved for sockets. If this type is undefined on the target sys¬ 
tem, the implementation may decide to ignore this file type and 
output a warning message. 


1564 This provides for extensibility of the cpio format while allowing for the ability to 

1565 read old archives. Files of an unknown type may be read as “regular files” on 

1566 some implementations. On a system that does not support extended file types, 

1567 the format-interpreting utility should do the best it can with the file and go on to 

1568 the next. 
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1569 4.48.9 Extended Description — ustar Interchange Format 

1570 HLJ: This is the text adopted from 1003.1LIS Draft 1. It has been left generally l 

1571 unmodified as a working group exercise. l 

1572 A ustar archive tape or file shall contain a series of blocks. Each block shall be a 

1573 fixed-size block of 512 octets (see below). Although this format may be thought of 

1574 as being stored on 9-track industry-standard 12,7 mm (0,5 in) magnetic tape, 

1575 other types of transportable media are not excluded. Each file archived shall be 

1576 represented by a header block that describes the file, followed by zero or more 

1577 blocks that give the contents of the file. At the end of the archive file there shall 

1578 be two blocks filled with binary zeroes, interpreted as an end-of-archive indicator. 

1579 The blocks may be grouped for physical I/O operations. Each group of n blocks 

1580 (where n is set by the application utility creating the archive file) may be written 

1581 with a single write_a_file operation. On magnetic tape, the result of this write 

1582 shall be a single tape record. The last group of blocks always shall be at the full 

1583 size, so blocks after the two zero blocks may contain undefined data. 

1584 The header block shall be structured as shown in Table 4-101. All lengths and 

1585 offsets are in decimal. 


1586 

1587 

Table 4-101 - tar Header Block 

1 

1588 

Field Name 

Octet Offset 

Length (in octets) 

1 

1589 

name 

0 

100 

1 

1590 

mode 

100 

8 

1 

1591 

uid 

108 

8 

1 

1592 

gid 

116 

8 

1 

1593 

size 

124 

12 

1 

1594 

mtime 

136 

12 

1 

1595 

chksum 

148 

8 

1 

1596 

typeflag 

156 

1 

1 

1597 

linkname 

157 

100 

1 

1598 

magic 

257 

6 

1 

1599 

version 

263 

2 

1 

1600 

uname 

265 

32 

1 

1601 

gname 

297 

32 

1 

1602 

dev major 

329 

8 

1 

1603 

devminor 

337 

8 

1 

1604 

prefix 

345 

155 

1 


1605 


1606 All characters in the header block shall be represented in the coded character set 

1607 of ISO/IEC 646 {1}. For maximum portability between implementations, names 

1608 should be selected from characters represented by the portable filename character 

1609 set as octets with the most significant bit zero. If an implementation supports the 

1610 use of characters outside the portable filename character set in names for files, 

1611 users, and groups, one or more implementation-defined encodings of these charac- 

1612 ters shall be provided for interchange purposes. However, pax shall never create l 

1613 file names on the local system that cannot be accessed via the procedures l 
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1614 described previously in this standard. If a file name is found on the medium that l 

1615 would create an invalid file name, the implementation shall define if the data l 

1616 from the file is stored on the file hierarchy and under what name it is stored. A l 

1617 format-reading utility may choose to ignore these files as long as it produces an l 

1618 error indicating that the file is being ignored. l 

1619 Each field within the header block shall be contiguous; that is, there shall be no l 

1620 padding used. Each character on the archive medium shall be stored contigu- l 

1621 ously. l 


1622 The fields magic , uname , and gname shall be character strings each terminated l 

1623 by a NUL character. The fields name, linkname, and prefix shall be NUL- l 

1624 terminated character strings except when all characters in the array contain l 

1625 non-NUL characters including the last character. The version field shall be two l 

1626 octets containing the characters "00" (zero-zero). The typeflag shall contain a l 

1627 single character. All other fields shall be leading zero-filled octal numbers using l 

1628 digits from ISO/IEC 646 {1} IRV. Each numeric field shall be terminated by one or l 

1629 more space or NUL characters. l 

1630 The name and the prefix fields shall produce the pathname of the file. The l 

1631 hierarchical relationship of the file can be retained by specifying the pathname as l 

1632 a path prefix, and a slash character and filename as the suffix. A new pathname 1 

1633 shall be formed, if prefix is not an empty string (its first character is not NUL), by l 

1634 concatenating prefix (up to the first NUL character), a slash character, and name ; l 

1635 otherwise, name shall be used alone. In either case, name shall be terminated at 1 

1636 the first NUL character. If prefix begins with a NUL character, it shall be ignored, l 


1637 In this manner, pathnames of at most 256 characters can be supported. If a path- l 

1638 name does not fit in the space provided, the format-creating utility shall notify the l 

1639 user of the error, and no attempt shall be made by the format-creating utility to l 

1640 store any part of the file—header or data—on the medium. l 

1641 The linkname field, described below, shall not use the prefix to produce a path- l 

1642 name. As such, a linkname is limited to 100 characters. If the name does not fit 1 

1643 in the space provided, the format-creating utility shall notify the user of the error, l 

1644 and the utility shall not attempt to store the link on the medium. l 
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1645 The mode field provides 12 bits encoded in ISO/IEC 646 {1} octal digit representa- l 

1646 tion. The encoded bits shall represent the following values of the file_mode_type: l 

1647 04 000 set_user_id_on_exec l 

1648 02 0 00 set_group_id_on_exec l 

1649 01 0 00 <reserved> l 

1650 00 4 00 owner_read permission l 

1651 00 2 00 ownerjwrite permission l 

1652 00 100 owner_execpr_search permission l 

1653 00 0 4 0 group pead permission l 

1654 00 02 0 group _write permission l 

1655 00 010 group _execpr_search permission l 

1656 00 004 other pead permission l 

1657 00 0 02 other prite permission l 

1658 00 0 01 other_execpr_search permission l 

1659 When appropriate privilege is required to set one of these mode bits, and the user l 

1660 restoring the files from the archive does not have the appropriate privilege, the l 

1661 mode bits for which the user does not have appropriate privilege shall be ignored, l 

1662 Some of the mode bits in the archive format are not mentioned elsewhere in this l 

1663 standard. If the implementation does not support those bits, they may be l 

1664 ignored. l 

1665 The uid and gid fields shall be the user and group ID of the owner and group of l 

1666 the file, respectively. l 


1667 The size field shall be the size of the file in octets. If the typeflag field is set to l 

1668 specify a file to be of type 1 (a link) or 2 (reserved for symbolic links), the size field l 

1669 shall be specified as zero. If the typeflag field is set to specify a file of type 5 l 

1670 (directory), the size field shall be interpreted as described under the definition of l 

1671 that record type. No data blocks shall be stored for types 1, 2 , or 5. If the l 

1672 typeflag field is set to 3 (character special file), 4 (block special file), or 6 (FIFO), l 

1673 the meaning of the size field is unspecified by this standard, and no data blocks l 

1674 shall be stored on the medium. Additionally, for 6, the size field shall be ignored l 

1675 when reading. If the typeflag field is set to any other value, the number of blocks l 

1676 written following the header shall be {size +511)7512, ignoring any fraction in the l 


1677 result of the division. l 

1678 The mtime field shall be the modification time of the file at the time it was l 

1679 archived. It is the ISO/IEC 646 {1} representation of the octal value of the l 

1680 modification time {timeJileJastpnodified) obtained from the get_file_status_by_- l 

1681 path procedure. l 


1682 The chksum field shall be the ISO/IEC 646 {1} IRV representation of the octal value l 

1683 of the simple sum of all octets in the header block. Each octet in the header shall l 

1684 be treated as an unsigned value. These values shall be added to an unsigned l 


1685 integer, initialized to zero, the precision of which shall be not less than 17 bits, l 

1686 When calculating the checksum, the chksum field shall be treated as if it were all l 

1687 spaces. l 

1688 The typeflag field shall specify the type of file archived. If a particular implemen- l 

1689 tation does not recognize the type, or the user does not have appropriate privilege l 
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1690 to create that type, the file shall be extracted as if it were a regular file if the file 1 

1691 type is defined to have a meaning for the size field that could cause data blocks to l 

1692 be written on the medium (see the previous description for size). If conversion to l 

1693 an regular file occurs, the format-reading utility shall produce an error indicating l 

1694 that the conversion took place. All of the type flag fields shall be coded in 1 

1695 ISO/IEC 646 {1} IRV: l 

1696 ' 0 ' Represents a regular file. For backward compatibility, a typeflag l 

1697 value of binary zero (' \0') should be recognized as meaning a regu- l 

1698 lar file when extracting files from the archive. Archives written l 

1699 with this version of the archive file format shall create regular files 1 

1700 with a typeflag value of ISO/IEC 646 {1} IRV 'O'. l 

1701 ' 1 ' Represents a file linked to another file, of any type, previously l 

1702 archived. Such files shall be identified by each file having the same 1 

1703 device and file serial number. The linked-to name shall be specified l 

1704 in the linkname field with a NUL-character terminator if it is less l 

1705 than 100 octets in length. l 

1706 ' 2' Reserved to represent a link to another file, of any type, whose dev- l 

1707 ice or file serial number differs. This is provided for systems that l 

1708 support linked files whose device or file serial numbers differ, and 1 

1709 should be treated as a type ' 1 ' file if this extension does not exist. 1 

1710 ' 3',' 4 ' Represent character special files and block special files respectively, l 

1711 In this case the devmajor and devminor fields shall contain informa- l 

1712 tion defining the device, the format of which is unspecified by this l 

1713 standard. Implementations may map the device specifications to l 

1714 their own local specification or may ignore the entry. l 

1715 ' 5 ' Specifies a directory or subdirectory. On systems where disk alloca- l 

1716 tion is performed on a directory basis, the size field shall contain the l 

1717 maximum number of octets (which may be rounded to the nearest l 

1718 disk block allocation unit) that the directory may hold. A size field l 

1719 of zero shall indicate no such limiting. Systems that do not support l 

1720 limiting in this manner should ignore the size field. l 

1721 ' 6' Specifies a FIFO special file. Note that the archiving of a FIFO file l 

1722 archives the existence of this file and not its contents. l 

1723 ' 7 ' Reserved to represent a file to which an implementation has associ- l 

1724 ated some high performance attribute. Implementations without l 

1725 such extensions should treat this file as a regular file (type ' 0'). l 

1726 ' A'-'Z' The letters A through Z are reserved for custom implementations, l 

1727 All other values are reserved for specification in future revisions of l 

1728 this standard. l 

1729 The magic field is the specification that this archive was output in this archive l 

1730 format. If this field contains "us tar" (the five ISO/IEC 646 {1} IRV characters l 

1731 shown followed by NUL), the uname and gname fields shall contain the l 

1732 ISO/IEC 646 {1} IRV representation of the owner and group of the file respectively l 

1733 (truncated to fit, if necessary). When the file is restored by a privileged, l 
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1734 protection-preserving version of the utility, the password and group files shall be l 

1735 scanned for these names. If found, the user and group IDs contained within these l 

1736 files shall be used rather than the values contained within the uid and gid fields. l 

1737 The encoding of the header is designed to be portable across machines. l 

1738 4.48.9.1 Rationale. (This subclause is not a part of P1003.2b) 1 

1739 This description reflects numerous enhancements over pre-1988 versions. The l 

1740 goal of these changes was not only to provide the functional enhancements l 

1741 desired, but also to retain compatibility between new and old versions. This com- l 

1742 patibility has been retained. Archives written using the old archive format are l 

1743 compatible with the new format. Archives written using this new format may be l 

1744 read by applications designed to use the old format as long as the functional l 

1745 enhancements provided here are not used. This means the user is limited to l 

1746 archiving only regular type files and nonsymbolic links to such files. l 

1747 Implementors should be aware that the previous file format did not include a l 

1748 mechanism to archive directory type files. For this reason, the convention of l 

1749 using a file name ending with slash was adopted to specify a directory on the l 

1750 archive. l 

1751 The total size of the name and prefix fields have been set to meet the minimum l 

1752 requirements for {PATH_MAX}. If a pathname will fit within the name field, it is l 

1753 recommended that the pathname be stored there without the use of the prefix l 

1754 field. Although the name field is known to be too small to contain {PATH_MAX} l 

1755 characters, the value was not changed in this version of the archive file format to l 

1756 retain backward compatibility, and instead the prefix was introduced. Also, l 

1757 because of the earlier version of the format, there is no way to remove the restric- l 

1758 tion on the linkname field being limited in size to just that of the name field. l 

1759 The size field is required to be meaningful in all implementation extensions, l 

1760 although it could be zero. This is required so that the data blocks can always be l 

1761 properly counted. l 

1762 It is suggested that if device special files need to be represented that cannot be l 

1763 represented in the standard format that one of the extension types ('a'-'z') be l 

1764 used, and that the additional information for the special file be represented as l 

1765 data and be reflected in the size field. l 

1766 Attempting to restore a special file type, where it is converted to ordinary data l 

1767 and conflicts with an existing file name, need not be specially detected by the util- l 

1768 ity. If run as an ordinary user, a format-reading utility should not be able to l 

1769 overwrite the entries in, for example, /dev in any case (whether the file is con- l 

1770 verted to another type or not). If run as a privileged user, it should be able to do l 

1771 so, and it would be considered a bug if it did not. The same is true of ordinary l 

1772 data files and similarly named special files; it is impossible to anticipate the l 

1773 user’s needs (who could really intend to overwrite the file), so the behavior should l 

1774 be predictable (and thus regular) and rely on the protection system as required. l 

1775 The values '2' and '7' in the typeflag field are intended to define how symbolic l 

1776 links and contiguous files can be stored in a tar archive. POSIX. 1 does not l 
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1777 require the symbolic link or contiguous file extensions, but does define a standard l 

1778 way of archiving these files so that all conforming systems can interpret these file l 

1779 types in a meaningful and consistent manner. On a system that does not support l 

1780 extended file types, the format-interpreting utility should do the best it can with l 

1781 the file and go on to the next. 1 

1782 4.51 pwd — Return working directory name 3 

1783 => 4.51.2 pwd Description. Replace the entire Description sublcause with: 3 

1784 The pwd utility shall write to standard output an absolute pathname of the 3 

1785 current working directory with all symbolic link components resolved. 3 

1786 Editor’s Note: The following rationale will he added to E.4.51, but is kept here 3 

1787 with pwd for this draft: 3 

1788 pwd Rationale. (This subclause is not apart ofP1003.2b) 3 

1789 HLJ: My version of the KornShell doesn’t do this. Is that correct? 3 
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1790 4.53 rm — Remove directory entries 


1791 => 4.53.2 rm Description. Replace item (2c) with: 

1792 For each entry contained in file, other than dot or dot-dot, the four steps listed 

1793 here [(l)-(4)] shall be taken with the entry as if it were a file operand. The rm 

1794 utility shall not traverse directories by following symbolic links into other 

1795 parts of the hierarchy, but shall remove the links themselves. 

1796 Editor’s Note: The following rationale will he added to E.4.53, but is kept here 

1797 with rm for this draft: 

1798 rm Rationale. (This subclause is not a part ofP1003.2b) 

1799 The rm utility removes symbolic links themselves, not the files they refer to, as a 

1800 consequence of the dependence on the POSIX. 1 {8} unlink () functionality, per the 

1801 Description. When removing hierachies with -r or -R, the prohibition on follow- 

1802 ing symbolic links has to be made explicit. 
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1803 4.62 test — Evaluate expression 


1804 => 4.62.3 test Operands. Add the following primary in the proper sorted order: 


1805 -h file True if file exists and is a symbolic link. 

1806 => 4.62.3 test Operands. Add the following at the end of the primaries list 

1807 (before the paragraph that begins “A primary can be preceded by ... ” 

1808 With the exception of the -h file primary, if a file argument is a symbolic link, 

1809 test shall evaluate the expression by resolving the symbolic link and using 

1810 the file referenced by the link. 
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Section 5: Revisions to User Portability Utilities Option 


i 5.9 du — Estimate file usage 


2 => 5.9.2 du Description. Add a new sentence in the first paragraph, following 

3 the sentence beginning with “The du utility, by default...” 

4 When a symbolic link is encountered in the file hierarchy, du shall count and 

5 write the name and size of the symbolic link itself (rather than the file refer- 

6 enced by the link) and shall continue with the other files in the directory con- 

7 taining the link, not attempting to follow the link to another portion of the file 

8 hierarchy. 
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9 5.39 file — Determine file type 

10 => 5.14.1 file Synopsis. Modify the Synopsis to be: 

11 file [—h] [/?/e ... ] 

12 = 5 - 5.14.2 file Description. Add a new paragraph at the end of the subclause: 

13 If file is a symbolic link, by default the link shall be resolved and file shall 

14 test the type of file referenced by the symbolic link. 

is =4- 5.14.3 file Options. Replace the entire Options subclause with: 

16 -h When a symbolic link is encountered, the link shall not be 

17 resolved and file shall identify the file as a symbolic link. If 

18 -h is not specified and file is a symbolic link that refers to a 

19 nonexistent file, file shall identify the file as a symbolic link, 

20 as if -h had been specified. 

21 => 5.14.6.1 file Standard Output. Insert a new paragraph between the second 

22 and third (the one beginning "If the file named ...”) paragraphs: 

23 If file is identified as a symbolic link (see -h), the following alternative output 

24 format shall be used: 

25 " %s : %s %s0 ",<file>,<type>,<contentsoflink> 


26 => 5.14.6.1 file Standard Output. Add the following entry to the table named 

27 file Output Strings: 

28 If file is a <type> shall contain the string 

29 symbolic link symbolic link to 
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Section 6: Revisions to Software Development Utilities Option 


There are no revisions to Section 6 (yet). 
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Annex A 

(normative) 

Revisions to C Language Development Utilities Option 


There are no revisions to Annex A (yet). 
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Annex B 

(normative) 

Revisions to C Language Bindings Option 


1 Editor’s Note: This annex is new for Draft 3. It is not further diff-marked. 3 

2 B.2.5 Pathname Variable Values 

3 => B.2.3 Pathname Variable Values. Add a new subclause, B.2.5, Pathname 

4 Variable Values, as follows: 

5 The macros in Table B-100 can be used by the application at execution time to 

6 determine which optional facilities relate to specific pathnames. A definition 

7 of one of the values from Table B-100 shall be omitted from <limits . h> on 

8 specific implementations where the corresponding value is equal to or greater 

9 than the stated minimum, but where the value can vary depending on the file 

10 to which it is applied. The actual value supported for a specific pathname 

n shall be provided by the pathconff) function. 

12 Table B-100 - C Pathname Variable Values 

13 

■ Name Description 

15 _POSIX2_SYMLINKS When referring to a directory, the system supports the creation of sym- 

16 bolic links within that directory; for nondirectory files, the meaning of 

17 {POSIX2_SYMLINKS} is undefined. 

18 _ 


19 => B.10.2 C Binding for Get Numeric-Valued Configurable Variables Add 

20 the following sentence to the end of the only paragraph in the subclause: 

21 In addition, the pathconfO and fpathconfO functions shall support the name 

22 values in Table B-101, defined in <unistd.h>, to provide values for variables 

23 in 2.13.3. 


Copyright © 1992 IEEE. All rights reserved. 

This is an unapproved IEEE Standards Draft, subject to change. 


Annex B Revisions to C Language Bindings Option 


71 



P1003.2b/D3 INFORMATION TECHNOLOGY—POSIX 


24 

25 

26 

27 

28 
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